Recently I’ve written about reinventing the product spec, and the reasons to move from a heavy-weight PRD to a light-weight high-fidelity prototype as the basis for your product spec. But where do these ideas come from, and how do you decide if you even want to build a product in the first place?

Opportunities for new products exist all around us, in every market, even mature markets. This is because what is possible is always changing. New technologies are constantly emerging, new people with new talents join your company, and competitors come and go. The product manager must be able to quickly evaluate opportunities to decide which are promising and which are not, and for the ones that look appealing, which ones should be pursued, which are best left for others, and which ideas are not yet ready for productization.

In many companies, it just comes down from above that we really need to do this product. In other companies, the marketing organization determines what products are needed.

In either case, too often the process of deciding whether or not to build a product is left to intuition (or worse, a large customer will offer to fund a “special” and this becomes the basis for a product effort).

Typically someone on the business side or in marketing will create some form of a Market Requirements Document (MRD) that is intended to describe the problem to be solved, and usually includes a business justification as well. The purpose of the MRD is to describe the opportunity, not the solution. At least that’s the theory. In practice, many companies don’t really do MRD’s, or if they do, they’re essentially product specs that are called MRD’s. When true MRD’s are done, they suffer many of the same problems as PRD’s – they take too long to write, they aren’t read, and they often don’t answer the key questions they need to.

The result is that many product managers ignore the MRD. But the problem with not doing anything and just jumping right into the product is that it is generally a good idea to look before you leap. The challenge is to do this in a quick, lightweight, yet effective manner.

I consider this “Product Opportunity Assessment,” as I prefer to call it, an extremely important responsibility of the product manager. The purpose of a good product opportunity assessment is either to a) prevent the company from wasting time and money on poor opportunities; or b) for those that are good opportunities, to understand what will be required to succeed.

Fortunately, it’s really not that hard to do a useful product opportunity assessment. I ask product managers to answer ten fundamental questions:

1. Exactly what problem will this solve? (value proposition)
2. For whom do we solve that problem? (target market)
3. How big is the opportunity? (market size)
4. What alternatives are out there? (competitive landscape)
5. Why are we best suited to pursue this? (our differentiator)
6. Why now? (market window)
7. How will we get this product to market? (go-to-market strategy)
8. How will we measure success/make money from this product? (metrics/revenue strategy)
9. What factors are critical to success? (solution requirements)
10. Given the above, what’s the recommendation? (go or no-go)

The hardest question to answer is usually the first, which surprises people because it sounds like the easiest. But ask most product managers what problem their product is intended to solve, and you usually get a rambling list of features and capabilities, rather than the a crisp, clear and compelling statement of exactly the problem that’s solved.

Another difficult problem can be in assessing the size of the opportunity. You can get thoughts on this from industry analysts, trade associations, your finance staff, and from your own bottom up calculations. This is a topic in itself, but for now just remember to be conservative and realize that not every opportunity needs to be a billion dollar market.

The “go-to-market” strategy is especially important as that describes how this product would be sold, which can have very significant impact on the product requirements.

The solution requirements refer to any special needs or requirements that were identified during the investigation. Again, we’re not describing the product here but rather making clear any dependencies or constraints. For example, if this is a product that will be sold through system integrators, then these types of partners have requirements around extensibility of the products they deliver. Similarly, there may be branding or partnership requirements.

A product organization is all about pursuing good opportunities and providing great product solutions. Opportunities for new products are everywhere, and it is important that the product manager be able to effectively evaluate new opportunities and identify those that have the most potential for the company. It is just as important that bad product ideas get identified at this stage, before significant time and cost is lost chasing them. Choosing the right set of products to pursue is among the most important decisions a company will make.

It is important that the results of the product opportunity assessment be presented and discussed with senior management, and that the company make a clear go or no-go decision on whether to pursue a product to meet this opportunity. If you do decide to proceed, you will be much better informed as to what you are getting yourself into and what it will take to succeed.

So what do you do if the CEO tells you that this is what we’re doing, so just get to work on the product? First, realize that there are sometimes strategic reasons for doing a product, so you might need to pursue a product even when it’s unlikely to succeed in the market. That said, I have found that doing this lightweight, quick product opportunity assessment is still valuable in that I become much better informed about what this product involves. It is possible that what you learn will change your CEO’s opinion, but more likely it is a good opportunity, and your CEO was right to want to pursue it, but at least now you know what you’re up against if you are to succeed.

Email to a friend

Sign up for the free newsletter here.

It’s funny how often I’m asked whether I am a “strategy guy” or an “execution guy.” I completely understand the reason for the question, as I think it’s true that most people prefer one or the other; in fact, they often very strongly prefer one or the other, or regardless of their preferences, their personality is only suited to one or the other. Yet for product leaders, it has always been very clear to me that you must be skilled in both in order to actually get good products launched.

In my mind, software projects can be thought of at the highest level as two phases: first figure out what to build, then build it. The first phase is dominated by strategy, and the second phase is all about execution. During the first phase, you welcome and explore new ideas, you talk with scores of users and customers, you learn how you can apply new technologies, you flesh out your product concepts and test them out, and you spend a lot of time thinking about the overall product direction, both immediate and longer term. it is all about discovering that mix of functionality and design that results in a winning product.

However, once you’ve spec’ed out this product, and your engineering team begins the process of building this product, a very profound and important shift needs to take place for the product team. Now the game is all about execution. Getting this product built, tested, and delivered to market. In this phase you spend your time keeping everyone focused, chasing down the countless issues that arise, and getting these resolved immediately. Acquisitions, competitors, organizational and management changes; these are all distractions, and your job is to keep the team on track so this product can get out there when it needs to be.

In countless product teams, this shift in mindset doesn’t actually happen, or at least it doesn’t happen until much later, often as late as entering QA. Instead, the product managers continue to explore new ideas, and company execs continue to view the product spec as malleable, and what results is euphemistically referred to as churn. Essentially, the product spec continues to change is significant ways, impacting engineering and the rest of the product team, and typically the release dates push out, or features get cut, or the quality gets compromised.

If you’re lucky enough to have a great project manager (see the “eBay’s Secret Weapon” article), then you probably have help keeping everything on track during this implementation phase. But even if you do, as a product manager you’ll need to be cognizant of this necessary change in mindset, otherwise it is all too easy for the product manager to be the source of the product’s inability to get to market.

But it’s important I think to recognize that we all have our own preferences and different skills. If you’re naturally a strategy kind of person, preferring the freedom and creativity of the invention process, then you’ll have to work extra hard to contain those urges during execution. On the other hand, if you’re more naturally the project manager type that loves getting things out the door, then you’ll need to work on your strategic thinking and design skills, and remembering that what matters is creating a product that your customers love.

One technique that I have found very useful is to always keep two versions of product going in parallel. In other words, as soon as you start the engineering for release 1.0, and you switch into execution mode for that project, then you can start up the strategy/design phase for release 2.0. Always keep that innovation engine working, just know that once a given release goes to engineering, you redirect your creative urges to the next release.

You do need to be careful that this doesn’t detract from the execution work for the current project, but overall I’ve found that having this outlet is a good thing. The next time a company exec drops by with a big new requirement, rather than impacting the product you have in the oven, you already have the next release in the design stage and you can accommodate the new requirements there.

I don’t mean to make this all sound easy, but I do believe that with discipline it can be managed. Just remember that it’s essential that you develop both your strategic skills (to ensure you’re coming up with winning products) as well as your execution skills (to ensure that these great ideas actually make it to your customers).

Email to a friend

Sign up for the free newsletter here.