Friday, October 30, 2009

From the Intrawebs - October 30

Halloween is my favorite holiday of the year. I hope yours is awesome (no way am I going to say "spooktacular"! Oh, wait, doh!). Don't forget to watch out for your future customers: drive slow and stay alert for kids out trick or treating.

Found some good stuff out there this week. Hope you enjoy it! If you are interested in seeing my picks in real-time, you can follow my From The Intrawebs RSS feed.

Wednesday, October 28, 2009

Career Change: How to Become a Product Manager

There are many paths into product management in the software world. Whether it is putting your product knowledge to work as a software engineer or your customer knowledge as a sales engineer, one thing that seems to be consistent is that you need a background in software to manage a software product.

I'm going to spend some time talking about how to make that change into product management. Many of these concepts will apply to anybody wanting to transition into product management, but we may cover some topics that are specific to where you are coming from.

As a starting point, let's identify and characterize some of the "standard" career paths that you can take in product development:

You can go down the technical path, becoming an architect or a principal engineer. I call this the "How" path, because your job revolves around how to accomplish the needs of the business.

Another path is into functional management, progressing from a team lead through manager and into director. I call this the "Who" path, because you primarily are concerned with who will accomplish the needs of the business.

Tangential to functional management is project management, which is the "When" path. Your primary focus is the scheduling of deliverables.

I would categorize the path through business analysis as the "What" path. This may be an intermediary step to get to product management for many people. As a business analyst, you define what needs to be built and delivered.

The last common option, and the one we are going to concern ourselves with, is product management. This is what I call the "Why" path.

Any time you change your career path, you will be required to change the way you approach solving problems.

I can see many people arching their eyebrows and muttering, "The product manager is the one who says 'What'." My argument is that the "What" is a by-product of understanding why a market exists and is experiencing a problem that your company is capable of solving.

I have a lot of ideas swirling around on the topic of making the transition to product manager, far too many for a single post, even with my (too?) lengthy prose. As such, I'm going to make it a series of posts.

  • In part two, we will discuss the mental shift required to move into product management. This is one of the most difficult steps and your success with this step will determine whether it is an appropriate career path. We will also discuss what you will give up when you make the switch.

  • Part three will explore how you can gain product management experience while you are still doing your day. There are many things you can start doing today to assist in your career change.

  • Part four will review options for gaining the remaining knowledge and experience you will need to make the transition.

  • Finally, we will wrap it up with a discussion of getting that all-important first job, including how to present yourself during your job search if the first job is not at your current employer.

I am going to bring multiple viewpoints into this discussion, both through conversations with others in the product management community, through the existing body of work already out there, and, hopefully, through your feedback.

Special thanks go out to Bob Corrigan for his early feedback on this topic. His ack/nak blog is a great source of Product Management information. You should read it!

Friday, October 23, 2009

From the Intrawebs - October 22

Here is this week's reading list...

Thursday, October 22, 2009

Everybody Is My Customer!

You are going to build an amazing product. It is going to revolutionize the way a market works. It is awesome to the extreme (Dude!). Because your product is so amazing, you know the entire market is your customer base. You certainly don't want to limit your sales potential by limiting your customer base to a segment of that market, right?


In the consumer and small biz software world, we generally shoot for a hockey-stick growth curve. Enterprise software is a little more difficult to have that kind of a growth curve because it is high touch, but we still would like to see the curve moving upwards. In both cases, though, each progressive sale becomes easier than the sale before it.

That is an important concept, so I will repeat it. Selling your product to the 1,000,000th customer will be easier than selling it to the 999,999th customer. In an exponential growth curve (e.g. the hockey stick), it is exponentially easier to make the next sell.

Being Infinitely Hard

OK, the first sell is not infinitely hard, but it is amazingly difficult (we'll ignore the copy Mom bought because she believes in your company...). The first buyer is buying completely on faith: faith that you will survive as a company and succeed as a product, faith that you will deliver the future you promise, faith that you will really solve her problems. Even if your product is free, a leap of faith is required just for the time investment required.

This is what you need to be thinking about as you plan your initial release. It is not the easy 1,000,000th easy sale, but the very hard first sale that matters.

Make It Easier

With that in mind, how can you make it easier? The closer your software and marketing matches the needs of a highly focused group in your overall target market, the easier that first sell will be. Now is the time to put your product management hat on, identify that focused group, and start building value specifically for them. As development continues, product marketing (yeah, it may be you again...) will start to craft a message tailored specifically to them. Your launch will be tailored around this tightly focused group, getting them on board, and making them extremely happy.

There is a fringe benefit to having a tightly focused group of customers: they form the foundation of your tribes, who are absolutely critical to your success.

With your tribe of happy customers, you are ready to conquer the world and start taking advantage of ever-easier sales. Remember, even Facebook started with just Harvard and dreams of owning the whole college alumni population. Imagine if Facebook had said, "We have a product perfect for every college student, we don't need to start with just Harvard." Do you really think they would be where they are today? Is your product poised for more success than Facebook was?

Friday, October 16, 2009

From the Intrawebs - October 16

This is the first installment of a weekly series called "From the Intrawebs." I will identify the best of what I read, watched, or heard through the week. This week's list is a little short, but better to start small than not start at all.

That's it for this week. If you have something that you think belongs on my must-read list, drop me a line in the comments or via e-mail.

Thursday, October 15, 2009

The Perfect Product to Manage

It's the ideal product to manage, right? A product that you, the product manager, are the ideal customer. Immediately, your workload is cut in half because you can validate your own requirements, your own messaging, and your own positioning. It's a product for you, after all.

Of course, this couldn't be further from the truth. The reality is that if you are managing a product for which you are the ideal customer, you need to be extra careful to ensure your own personal biases and assumptions are not polluting your product.

When you start hearing yourself thinking, "Yes, this would make my work so much easier," or, "No, I would never use that kind of feature," you need to get out and start talking to your market to validate that it would make their work easier and that they would never use that feature.

Otherwise, you may wind up building a product for which you are the only customer.

Tuesday, October 13, 2009

How Soon Do You Need a Product Manager? (Part 2)

I've kind of had a theme going on here over the last few posts. I started with How Soon Do You Need a Product Manager. Then I told the story of a company that failed to capitalize on its awesome technology because of a lack of market focus in The Influence of Tribes on Product Success. Finally, I pointed to some others who share my views on the importance of product management in early-stage companies in "Hire Product Management First". Now it's time to wrap this theme up (for the time being, anyway) by responding to my closing comment in How Soon Do You Need a Product Manager: "But, but, but, we are a start up. We can't possibly understand customers, market, and products until we release something. Then the market will tell us where we are wrong."

This way of thinking has been codified in many software entrepreneurs' minds by writings by Paul Graham, Eric Raymond, and, really, by the entire Agile movement, all of which is very good advice. Unfortunately, it is taken as a replacement for customer development instead of an important piece of it.

Starting Up Without a Product Manager

Founders are good at identifying gaps in existing markets and building new companies to fill those gaps. Customer development in a start-up is often nothing more than some vague impressions about the under-served markets defined by those gaps.

Now the company turns inwards for the next six to nine months, maybe a little less for those that really get release early, maybe a little more for those that don't. The features in the first release are all determined by anecdote, by socializing, or by fiat. Everybody in the company is convinced of how great the product is because they keep telling themselves that and there is nobody to disagree.

Now we are coming to release and the company starts looking outward, really for the first time. The company doesn't really know who its customers are, so, in order to find any customers, it needs to shout into the crowds. The goal being to get some subset of the under-served market the founder identified to self-select and become a customer. Depending on the size of the market and how well defined it is, that can be a lot of shouting.

Maybe some customers trickle in, maybe they don't. If they do, revision two of the software is all about pleasing them, and the company needs to move quickly. If they don't trickle in, then revision two is all about throwing another dart at the dartboard to see if it gets closer to the market's needs. The scary thing about this is that the product may be perfect; other factors, such as positioning, messaging, or any of a host of other non-technical reasons, may be keeping people from buying.

Starting Up With a Product Manager

The whole goal of starting up with a product manager is to ensure that, at release time, there are some customers excited for the product. She will do this through a series of activities, all of which are outwardly focused, but will be affecting activities internally.

  • Identify and define the subset of the market that will buy.

  • Identify their greatest pain points and ensure development solves those.

  • Identify who is competition, who is a potential partner, and who is irrelevant.

  • Understand what the minimum feature set is that will enable a customer to jump to your product.

  • Analyze what communications channels will get the potential customers' attention.

  • Determine a message that will resonate with potential customers.

  • Enlist the first customers to provide feedback prior to release.

  • Price the product.

The product manager will look at the under-served market the founders identified and determine specifically how it is under-served. Who is the competition and how are they not servicing those needs? How can your product be positioned relative to the competition?

The product manager will start with the under-served market the founder identified and segment that until she finds a small group of potential customers that can be communicated with directly.

Isn't the Founder the Product Manager?

Actually, the ideal is for a founder to be the product manager. The company would be in a great position if a founder, passionate and visionary, was also the one who was ensuring the company had customers ready for the product it was building. If that's your situation, run with it. You are in a good position.

Many times (most?), however, founders are technology, finance, or sales people. These are great people to have involved in a start-up, but rarely do they have the experience and knowledge of how to drill down from a market to customers and then build back up from a concept to a product that those customers will buy (as opposed to a product that they think is killer).

Release early, release often. It is one of the great strengths of a start-up. Don't waste that strength by needlessly spinning wheels trying to figure out what a customer might want. A good product manager, properly empowered, will give you strong hypotheses. At that point, releasing early and often is about optimization, not about feeling around blindly for the market.

Isn't it worth one person in your company to keep all of the developers, QA, marketing, and sales focused in the right direction?

Friday, October 9, 2009

"Hire Product Management First"

In How Soon Do You Need a Product Manager, I argued that product management should be hired very early in a company's life. In The Influence of Tribes on Product Success, I told of what happened to one start-up that did not successfully managed the gap between technology and customers.

It turns out, I'm not the only one who feels this way. Check out this post by Saeed at On Product Management blog. In short, Bill Campbell, CEO of Intuit agrees.

If you have a start-up, don't under-estimate the value of a product manager. It is about far more than just prioritizing features!

Sunday, October 4, 2009

The Influence of Tribes on Product Success

I've been reading Seth Godin's Tribes. It's a short, quick read like most of Seth's books. I've also been reading Steve Blank's series on the customer development model. The combination has me thinking about successes and failures I've seen. Two in particular come to mind as particularly illustrative.

What's come to my mind as I've thought about these is the coolest product in the world is worthless if you can't connect with a buyer, and, conversely, the minimum required product may be much smaller than you think it is and the level of finish required may be rougher than you expect. Many companies spend countless hours on building the most amazing widget with the assumption that the customers will flock to them, only to be disappointed. Other companies put out something barely distinguishable from cruft, yet they maintain a loyal following. The difference is in the approach to developing customers, or in building a tribe.

Story Time 1: Starting with Customers

We were selling a web content management system for colleges. We initially tried to OEM a product from a partner, but that product failed to meet the needs of our market in so many ways, so we decided to build.

For a variety of reasons, we were actually able to freeze most of the market for nearly two years while development went to work. During that time, we were working very closely with a small set of customers who understood the problem and wanted to be at the bleeding edge of solving it.

As we started to get closer to the release, we brought in new customers to this group. Our initial customers had told us what would resonate with the type of customer we wanted to sell to. With this set of customers, we were able to test that resonance. I was surprised at how strongly this group of customers supported us. We had a small group of customers that were talking positively to other potential customers about our product, and they hadn't even seen it yet.

A Doomed Product?

Release came and, to be completely honest, the quality was...hmm...abysmal seems fitting. We pushed something out the door that we knew wasn't ready, but we were a year late and the market that we had successfully frozen was thawing rapidly.

A poor product, a year late, sales and services not ready for the release, a product manager leaving the company, competition increasing and maturing. Certainly the product was doomed, right?

Our Customers Make Us Succeed

Amazingly, no, it wasn't. It was not an easy year after that release, but we had invested enough in our customers that they wanted to make sure we succeeded. They gave us every opportunity to make things right, continuing to be positive voices for our product even when going through pains caused by us.

Yes, it was in their own interest for us to succeed at some level, but none of these early customers had invested so much in the product that they couldn't have pulled back. Instead, because we focused on really understanding the target market, engaged very deeply with that market, and committed personally to them, we built real relationships. We were leading a tribe and the tribe wanted us to succeed.

Story Time 2: Platform as a Service

I don't have the complete history on this one, as I wasn't there the entire time. I will paint as complete a picture as I can, however. I was not involved with managing this product; I watched this from the proverbial side-lines.

This product was one of the coolest products I've worked with. Even now, I think about what these guys are doing, and I'm impressed. Leveraging the move to the "Cloud", this company is building a web-based development environment. Imagine an environment where you can build incredibly interactive web applications (including drag and drop, dynamic lists, and all sorts of other AJAXian goodness) all within your browser. Now, take it one step further, and imagine that the cool app you just built could be versioned and deployed to the web by clicking the Deploy button. Very impressive stuff, and it really worked!

Build It and They Will Come...Right?

"Yelling at the crowds" is what Seth calls it. We were really good at doing it. The press knew who we were, and they liked us. We talked to a lot of people at trade shows. We gave away a lot of shirts. We even had a podcast. Oh, and we had a freaking amazing product. Surely people would be beating down our door, right?

Lots of people would come check out the product. They'd sign up for an account, tinker for a couple of hours, and disappear. Not very encouraging.

Managers Will Get It!

Well, developers are a religious lot with deep convictions in their development tools, so we'll go to their managers. How could their managers not love the value proposition we are selling? Hire a business dev guy (not calling it sales because we're not an enterprise software company and we will not have a sales staff) to help guide companies in and hire a program manager (oh, hi, that's me) to guide them through and back out again.

We have some luck talking to big names and some luck developing some software for no-names. We have no luck getting big names to try developing (much less buying anything). The no-names are companies so small or project so insignificant that nobody cares. Those companies are there because they are getting custom software for free. Huzzah!

What Happened?

A few months later (a long time at a start-up), and the company suddenly gets a LOT smaller. A month later, and it gets even smaller (oh, bye, that's me). Over the next six months, it continues to get smaller. But this technology is freaking awesome! What happened?

Turns out, we never knew who our customer was. We were so busy building a cool technology that we didn't stop to figure out who was really going to pay for it. Everybody in the company was an engineer, so we didn't need to go outside the company to figure out what to build. We built what we would use (well, not quite, but that's a story for another day). We just kept telling ourselves that every developer is our customer; it's a big pool, so we'll be fine..

For two years, the company was heads down, building an awesome technology, but never stopping to figure out who was going to buy it. They drank their own Kool-aid to the point that they knew people were just going to flock in. All they would need would be a gentle nudge in the right direction. All of their energies were focused inside the company.

Where Did They Go Wrong?

We could talk a lot about the specifics of this case and what went wrong. I think it would make a fascinating case study and maybe one day, I'll sit down with the founder, the CEO, and a few others, and make such a case study. Not today, though.

Instead, we'll paint with a broader brush and identify a few key points:

  1. Focused Inwards on Technology: It is a great technology, but they told themselves that too many times. They turned all their energy inwards to build it without ever vetting that they could sell it or understanding whom they would sell to. A technology is not a business. Even the employee balance in the company reflected this with well over 50% of the company in engineering.

  2. Didn't Build a Tribe: They never built a tribe around their product. This product had some unique constraints that made it very hard to build a tribe around. Even today, I'm not sure who the right customer is. If you can't answer that question, you don't have a product. If you don't have a product, you don't have a business.

  3. Features Weren't Focused: Because there wasn't a targeted customer guiding the development, features weren't prioritized to sell to that customer. Instead, they were prioritized based off of the importance to the technology.

Like I said, I don't know all of the history that lead to this outcome, but I did see the outcome, as of the end of last year. I hope they've addressed these issues, because if they haven't, I would question their ability to succeed.

Wrapping It Up

My experiences are anecdotal, I fully admit. However, they are illustrative of larger patterns that have been documented many times by many people. These are the stories that caused people like Steve Blank and Seth Godin to write what they did.

It is easy to get wrapped up in the product for the product's sake. Doing so is a recipe for disaster. Whether you call it customer development or building a tribe, the end result is that you need to understand who is laying out the cash and why they are willing to do that. Once you do that, you will understand what you need to do to lead them, whether there are five or 500 customers in your tribe.