Don't Hold Your Breath
Mark Hoover, President, Acuitive, Inc.  

The tips provided in last month’s Musing for successful Product Management were oriented largely towards managing products and programs that were already in place – fairly well defined, budgeted, and approved.  This month’s Musing is focused on the process for conceiving and validating new products or services.  To the degree that the product is critical to the success of a company, as is usually the case with a start-up, this Musing is about a process for determining the company strategy.

Product success is probably about 1% inspiration and 99% perspiration.  But over the years, a lot of people have expended a lot of sweat on product programs that were doomed from the start due to the lack of good inspiration.  The critical 1% puts you in a position where you can possibly succeed with good execution, as opposed to banging your head against a wall for months and years on end with no hope of success.  

From the outside, developing product strategy appears to be very fun.  So fun, in fact, that almost everyone in a company believes they have a knack for it.  If you could overhear most lunchtime conversations (to the degree they are about work at all), I bet that 95% of them are about product ideas.  These conversations usually contain the phrases “THEY just don’t get it,” and/or “if only THEY would build my widget idea, our stock price would zoom to the moon!”  But, developing a strategy is a lot of hard work.  What most people don’t appreciate is the total amount of effort required to develop, test, market, sell, and support a product.  Any given product, especially a new product, can consume a huge amount of company resources. Therefore one does not launch new product programs lightly – without studying the potential return-on-investment carefully.  When invited to join a product concept development process, most people eagerly join in.  But after about two or three meetings they start to drop out like Dodgers fans beating LA traffic, as they realize the fun brainstorming part is quickly followed by a lot of thorny questions, a lot of hard work, and a lot of invalidation of ideas that previously sounded cool.

Developing a product strategy is also a specialized art and science.  I know many executives who can run circles around me operationally who are terrible at strategy development, usually because they can’t see the forest for the trees.  Many technologists are also bad at developing product strategy because of an ingrained belief that technology “coolness” wins the day.  Most successful (and unsuccessful) sales people are horrible at product strategy, because it involves a large component of “trajectory visualization” which runs counter to their quarter-by-quarter focus.  But none of that stops any and all of these people from eagerly “helping” the process.

Looking back on my career, when strategizing was something you did briefly every two years or so after a period of heads-down development, I can see that my early efforts in this area were naïve and weak.  It’s only now, after five years as a strategic marketing consultant, exercising my strategy muscles day-in and day-out, that I really feel I am “on my game.”  And no, it’s not due to steroids or other performance-enhancing drugs – it’s due to continuous training. 

In this Musing I’d like to share with you a few aspects of a time-tested process for developing a product strategy.  Since my experience the last few years has been heavily oriented towards start-up strategies, most of what I am going to share with you directly applies to that situation.  But this process can also apply to product strategy exercises at larger companies for programs in which a fairly substantial “bet” is being placed on how resources are utilized.  What these insights probably do not apply well to are the process of defining feature releases to existing products, evaluating cost reduction programs, and other such incremental (but very important) shorter term product decisions.  In these cases, internal representatives from Engineering, Sales, Customer Support, Manufacturing, etc., can generally be polled or leveraged in some way to arrive at the proper conclusion, whereas for the types of situations I am going to talk about, they cannot. 

You Are Done When You Are Done, And Not Before

By far, the biggest mistake people make in developing a critical product strategy is to try and schedule the end date of the overall process.  This is a natural thing to do.  You want to know when you’ll arrive at a conclusion. You want to establish a forcing function for people to rally around.   Or maybe you just simply want to make sure you have a strategy before you run out of seed money.  But it’s not that easy to schedule the end date of a strategic process, because it is an iterative process, not sequential.   

You are done only when you have identified a critical problem to be solved for a targeted customer set for which you can build a differentiated solution that they will buy enough of to create an interesting revenue stream relative to your costs of development, marketing and support.  Now, go out and find me one of those in two weeks. Or four. Or eight.  Or whatever.  Anywhere in the process, you may find a fatal flaw in the proposed strategy and have to go back and re-think and re-validate all other aspects of the strategy.   You can’t really set an end date for completion.  At best, you can set incremental targets for the completion and review of a particular iterative cycle, and then either declare victory at the end of that cycle or kick off a new cycle based on warts exposed in the previous cycle.  Via this process, you might get lucky and be done long before you might have initially hoped, or the process could drag out much longer than you had hoped.  But until you can match a technological idea to a customer problem that can be profitably solved, you are not done. 

Focus On One Strawman Proposal At A Time

An iteration of a strategic analysis requires looking at a lot of different aspects of the success equation.  Who are the customers?  How many of them are there?  How do they make buying decisions?  What are the high level architectural characteristics of what we would build for them?  What would it cost? How does this compare to competitive solutions? Through what channels would we sell and support this product or service?  How would we price it?  How many would we sell?  Would we profit from this product program?   It takes a lot of work to evaluate all of these dimensions of a program, and to keep all of the analysis coordinated and consistent. You can only do this if you are analyzing one concept at any given time.  Trying to juggle too many different options reduces the clarity of the analysis of any one option and you end up with muddled information and muddled decisions.  So in the beginning, you may want to brainstorm to create a list of strawman customer problems to solve (not product ideas – let the customer problem drive the product), but then you need to quickly prioritize that list, usually based on nothing more than gut feel. Then start at the top of the list to evaluate them. At the end of an iteration cycle, you can determine that either (a) you’ve found your product strategy!  (move to execution ASAP), (b) the strawman seems viable but the details need to be re-worked through another iteration, or (c) the idea has been invalidated, now let’s move to the next strawman idea on the list. 

You’ll probably find that you get to (a) above in the 1st iteration on the 1^st strawman about 0.1% of the time.  Keep your expectations reasonable. 

But let’s say you do identify a winning product strategy in an early iteration cycle.  What should you do? Should you run with this or should you keep going down the list and evaluate all of the other strawman options, in order to find the most optimal strategy for you?  If you are an academic institution, you should definitely keep going down the list until the grant money runs out.  But if you are a real business operating in the real world with real business objectives, take that 1^st idea that makes the cut and run with it.   It’s very, very hard to find a match between technology ideas and customer needs, and if you are lucky enough to find one – go for it and don’t look back.

Don’t Fall Into The “Let’s Build It And See” Trap

In contrast to the above scenario, it’s more likely that you’ll churn and churn through many iterations of the process, never finding a strategy that feels just right.  Because there is such an underlying drive among the team to “do something,” there is a tendency in situations like this to subvert the process, grab one of the strawman proposals, adjust some of the thorny assumptions and parameters to make it look a bit more viable, and go forward with a “let’s build it and see” attitude.  

Avoid this at all costs.  If you are an existing company you are better off re-directing resources into improving or cost reducing your present products if you can’t find a new product strategy that “feels right,” even after six months of trying.  If you are in a start-up you just may have to admit that the stars and moon don’t seem to be aligning for you right now and disband.  There is no law that says there is a great idea out there just because you decided to launch or join a start-up. Do you want to invest the next two years of your life pursuing something that may be flawed from day one, just to prove out later that it was? 

You’ll know you’ve drifted into this mode if you say as a rationalization “we can always adjust the strategy later as we learn more.”   That statement ignores the inertia created by setting a particular plan in motion – inertia that makes it increasingly difficult to re-direct later.  Another thing you’ll say or hear if you are in this mode is “most successful start-ups weren’t successful building what they originally set out to build.”   I have a countering corollary I respond with when I hear that statement:

All unsuccessful start-ups either never delivered a product or they were unsuccessful with their first product.

The point of my process is to force the re-directs to occur up-front, before much investment has been made and inertia created.  If your 1^st iteration on your 1^st strawman idea doesn’t pan out, that forces you to look at alternatives. When you find an alternative that does look good, you’ve achieved a kind of accelerated and low cost re-direct that you can brag to your friends about five years later when telling the story about how you got to be a multi-gazillionaire. 

Start Each Cycle Of The Process Focused On A Particular Customer Problem

Ideally, new product or service ideas would come out of a specific definition of a customer need, and then an investigation of whether there is a viable technologic solution to the problem.  Sometimes it happens that way.  But more often, the catalyst for thought is a new technical concept that is looking for a problem to solve.  In that case, it is critical to back up and hypothesize a strawman customer problem that you hope to solve and then start the iterative cycle with focus on the customer you hope to sell to – detailed target customer definition, problem definition and quantification, buying criteria, influencing factors, the needs of the people they sell to or serve, etc.  Everything else in an analytical cycle keys off that grounding of the customer definition – product definition, competitive comparisons, willingness-to-pay, market sizing, partnering strategy, channels strategy, etc.

Often, a particular technical idea could be applied to different customers to solve different problems.  In our process, each of those customer/customer problem scenarios is a different strawman.  Choose one to drill down on and validate it or invalidate it.  If it doesn’t work out, go to the next one on the list.  If none of the customer-oriented strawmen generated from a single technology idea make sense, than the value of the technical idea is invalidated.  Don’t force it.

Avoid Premature Detail

The process I have described for creating a strategy involves lots of iterations on lots of strawman proposals.  If you don’t manage it right, it could take years to execute on such a process.   The way to avoid this is to accelerate the completion of each iterative cycle.  And the way to do that is to avoid premature detail.  

For the 1^st iteration, a lot of detail is needed about the target customers and their needs. But less detail is needed about the product definition and programmatic characteristics.  Ballpark estimates are acceptable for schedule, development costs, customer willingness-to-pay and market sizing.  The competitive analysis just needs to ensure that there are no market leaders that are well on their way to having this problem solved in the eyes of the target customers.  Almost no information is needed on the partnering or channel strategies.  Many ideas are generated by technical people and those same people tend to want to drive the technical details too deeply too prematurely.  The 1^st iteration is largely one of validating that there are customers out there with the assumed need, who would react well to a solution as described at a high level.  If this iteration passes muster and justifies another iteration on the same strawman, then more detail about the customer willingness-to-pay, product architecture, COGs estimation, development schedule, competition, resource requirements, and market need to be laid in for the 2nd iteration.  If this iteration passes, you are probably starting to hone in on this as your strategy, and now more detailed work on the product definition is warranted.

Spend Lots Of Time With Target Customers

There is only one way to get the kind of customer information you need to verify their pain points, how they think about solving them, what their buying criteria is, who influences them, their view of where to look for solutions, how they are organized, what their willingness-to-pay is, etc., and that’s to talk to them directly.  As a Product Manager, you should probably be spending 15-20% of your time with customers anyway. But if you are in a product planning cycle, especially early in it, that percentage should rise to 60-70%. 

When talking to customers in an investigative phase, you need to try to avoid selling them on your ideas.  That either turns them off or influences them to buy in without expressing to you their underlying needs and motivations.  Either way, your goals for the meeting are diluted, even though you’ll inevitably characterize the latter case as a great success when you report back later.   Instead, you need to get them talking about themselves.  To prepare, you must determine precisely what the half dozen or so key things you want to learn at the meeting are, and drive the discussion towards that.  This doesn’t necessarily mean that you walk in to the meeting with a prepared presentation or go down a list of questions that you ask directly.  It’s better to get the customers talking about themselves, possibly through a whiteboard discussion or by having them present to you.  Basically, you want to nurture a “what-if” kind of dialog. In the course of that, you can work your questions in if the topics don’t come up naturally.  

The true art, however, is in interpreting and future-mapping the customer information received.   Generally, end customers can’t necessarily anticipate the pain point of next year, or articulate exactly what a solution should look and feel like.  Service Provider customers are a little better at this and OEM customers are even better.  But still, no one will be able to completely and precisely tell you what they will be willing to buy a year from now, not to mention two or three.  It’s up to you to connect the dots between today’s pain points and criteria as expressed by these customers, technology and market trends that you believe will influence their thinking in the future, and your own product/service ideas to form a picture of how they will fit into that hypothetical future world.   This is an art and there is a sense of “feel” to it more than number crunching.  But your “feel” will be a lot better if you’ve spent a lot of time with targeted customers so that you can get a good strong sense of what it is like to be in their shoes.  Keep track of your assumptions and assertions as you make these projections. You’ll want to constantly re-test them in the future as part of an early warning system. 

I can’t over-emphasize how important direct customer interaction is.  Although I must say, it’s only important if (a) you want to raise money, or (b) you want to have a successful product.  So I guess it’s situational…

Market Research Data Is Critical…

if you are looking for fuel for your fireplace.  Or if you need a stack of paper to keep your door open.  Or if you need some extra paper for your baby daughter to draw with her crayons on. 

Maybe I’m being too critical, but to me Market Research is good if you need to apply it to the past, the present, or maybe even the immediate future.  But product strategy is about trajectory.  Often you are predicting what will be needed and what the market opportunity will be two, three, and four years out or more.   Nobody can really predict that well.  The people who perform market research generally get their numbers by polling a few end users who can’t predict the future themselves, and supplement that with polls and questionnaires that are full of multiple interpretations, received from a set of people for whom their statistical relation to the total market is unknown.    I’m not suggesting there is necessarily any better way to perform general market research, but that you should take the numbers with boulder-sized grains of salt.  These reports can get you into the ballpark of what the market may look like under one set of assumptions, and that’s about it. 

The way to get a good feeling that a market really exists, and the nuances of how the collection of customers that makes up that market segment think, is to talk to them directly.  I’ll take the knowledge learned from 20 direct conversations over the information gained from 1000 questionnaire responses interpreted by a third party, any day.  Generally, I feel that if I can find 10-20 customers who have the problem I am postulating, and tell me that my proposed solution is better than anything else that they are aware of, I can assume that there are a bunch of other customers I haven’t tripped over yet that are in the same situation.  And if not, I’ll just sell successfully to those customers, establish a beachhead, and figure out some other strategy to expand my opportunity. 

However, the VCs and your bosses will want you to base your projections on some quotable source, so write down the relevant numbers before you line your pet bird’s cage with it. 

What’s Next?

This Musing is focused mostly on the relatively boring process of establishing a product strategy.  I haven’t told you much about philosophies, rules of thumb, secrets, laws, corollaries, pitfalls to avoid, hard-learned lessons, fundamentals, prescriptions, formulas, or other tools to apply via this process to arrive at a successful product strategy.  This is the fun stuff.   We’ll dig into that with the next Musing. 

(volume 4, number 8)