11a. Getting Re-Oriented

• Let’s revisit what we’ve covered and where we’re headed.
• Sections
• Welcome
• Defining a product, different PD methods, goal of PD
• Some basics: what is good PD, what is value, the PD team, metrics
• Marketing 101
• Strategy 101
• Product Market Fit and Voice of the Customer
• Identifying Customer Needs
• Customer Needs: Design Thinking
• Customer Needs: Jobs to Be Done
• Customer Needs: JTBD and Outcomes
• And now we’re headed toward this fun stuff:
• 11. Initial Problem Definition
• 12. The Product Spec
• 13–14. Concept Generation
• 15. Concept Selection
• 16. Prototyping

As you can see, we’re nearly moving out of the problem space and into the solution space.

Problem Space = Voice of the customer, Customer Needs, Jobs to be Done, Problem Definition

Solution Space = Concept Generation, the Product Spec, Prototyping

For the next few days, we’ll talk about the problem definition and wrap up the Problem Space.

We’ll discuss:

• The Fuzzy Front End
• Iterating
• Problem Definition

Let’s do this thing

11b. After Discovering Customer Needs, the Next Step is . . . Uh . . . Uh Oh.

After “discovering customer needs,” some experts agree that the next step in the PD process is concept or idea generation. This includes activities like brainstorming, divergent thinking, patent scanning, competitor benchmarking, open innovation, and idea solicitation.

Other experts suggest building a business case at this point — confirming whether there really is a profitable opportunity to build a successful product.

Still, other experts suggest that not only is a business/market assessment a critical activity at this point, but that a strategic and technical assessment of feasibility must be completed.

Still, other experts talk about writing an initial product spec or problem definition at this point.

One Size Does Not Fit All

Why the F is there so much variation at this point in the product development process?!

Two reasons. The first reason is that the front end of the product development process is inherently fuzzy. That means there is uncertainty. More on this later.

The second reason is that not all products should be developed in the same manner, so everyone’s product development process and product development strategy will be different.

I made up a saying to describe this: “Different Strokes for Different Folks.” Pretty catchy and original, right?

Without diving into all the various types of markets and product-types out there, suffice to say that there are variations a-plenty:

• Mature versus growth industry
• Incumbent versus disruptor
• Software versus hardware
• First-generation versus line-extension
• Service versus product
• Funded versus bootstrapped

See what I mean? The idea that you could follow a single roadmap for product development in all of these unique situations is ridiculous. Reee-diculous.

There are indeed some elements of product development that are universal. (Understanding customer needs is universal; understanding the problem space as a whole is universal.)

What you should do once you “understand the problem space” is not so universal; it’s market- and product-dependent.

And distilling it into a simple summary ain’t gon’ be possible. But that isn’t going to stop me from trying to do it.

Fair warning, I’ll use the term “it depends” a lot and will also simply point you to various resources and let you figure out what’s right for your situation.

More on the Fuzzy Front End next.

11c. The Fuzzy Front End

The Fuzzy Front End is a term coined by Donald Reinertsen and it’s used in many product development books. It’s a concept you should know about.

The fuzzy front end describes the phase in product development in-between when an opportunity is identified and when serious effort is put forth to develop the project.

1. First part: Opportunity is identified
2. Then: The Fuzzy Front End
3. And Finally: Serious effort is made to develop the project

Why so Fuzzy?

The front end of product development can be uncertain because, well, we’re still dealing with a lot of uncertainty.

Let’s imagine ourselves in this phase. We’ve just done a bunch of voice-of-the-consumer type activities, and we feel like we have a pretty good idea of customer needs. Here’s a summary of our situation:

We have an understanding of the customer needs, but only insofar as they relate to existing conditions and products. We haven’t actually probed the customer with our own concepts and tested possible solution prototypes, which is when a lot more learning happens.

We also don’t know exactly what product concept is going to solve the customer’s problems best, and we’re not sure how long it’s going to take to find that solution. The solution space is still a mystery to us.

What is also a mystery is how to find the solution most efficiently. Should we immediately start prototyping and testing with customers; after all, iterating with customer input is critical, right?

But then again, we don’t want to invest in something that hasn’t been vetted properly for strategic alignment, market feasibility, and technical feasibility; perhaps we should instead organize all of those documents and hold a stage-gate meeting?

Also, we might not even have funding for this idea. We might be discovering this opportunity as a side project while doing something else entirely. Your project might need to get approved and blessed before you can even proceed.

See what I mean by fuzzy and uncertain?

Oh, and did I also mention that the product development process is typically highly iterative and non-linear? So not only is it fuzzy, but it often requires a few different approaches.

So again, the idea that we can continue to treat the PD process as a step-by-step process sort of breaks down after the universal front-end of understanding the problem space.

In Summary

In short, the front-end of product development is about understanding the problem space, but transitioning out of the problem space and into the solution space is not a one-size-fits-all process. There’s uncertainty, iteration, and situationally-specific considerations to make.

11d. So What Happens Next?

OK, I’ve taken two long posts to establish that the transition from the problem space to the solution space is fuzzy, product- and market-dependent, iterative and non-linear.

“Awesome! You’ve confused the shit out of me!” — You, right now.

Well, first of all, get used to it — ambiguity exists in life, and it exists in product development.

Second of all, relax . . . there is actually something concrete we can say about this Fuzzy Front End and this phase right after discovering customer needs. Here it comes:

The Problem Definition

In most instances, the step after identifying customer needs should be to organize everything you know about the problem space so that you can effectively come up with product solution concepts in an efficient manner.

We call this step, “problem definition.”

Different books will define this phase in different ways because problem definition looks different depending on whether you are a disruptive startup or an incumbent creating a derivative product.

But here’s the general definition: The problem definition process should be a deliberate and thoughtful process of organizing the current knowledge of the problem space, synthesizing information, identifying constraints, and essentially doing any and all feasibility studies that you believe are necessary for your situation.

I like to call this phase, “drawing the box.”

The box tells you what is in-bounds.

It clarifies those constraints you identified when thinking about the job to be done. Constraints include price, size, regulatory issues, and “must-haves” standard in the industry.

It’s important not to skip this step

“Of all the steps in the engineering design process, problem definition is the most important. Understanding the problem thoroughly at the beginning aids immeasurably in reaching an outstanding solution.” — Engineering Design, George Dieter.

Here’s another one:

“Go slowly and carefully first so you can go faster later.” — Steven Haines The Product Manager’s Desktop Reference

Some more on the problem definition in the next post.

Sources

Engineering Design is a textbook with a lot of technical info. I wouldn’t recommend it unless you’re an engineer or want to get pretty darn technical. It has a wide mix of content, from general PD processes to statistics and materials and other engineering disciplines.

Steven Haines’ The Product Manager’s Desktop Reference is an excellent book, and I think it belongs on your shelf if you work in PD. It’s highly referenceable, which I find to be super important in a reference book. It’s not too technical and provides a great 101 summary of PD and marketing/business-related topics.

11e. Wrapping up Fuzzy Front End and Problem Definition

OK, we’ve established that the front end of the PD process has some uncertainty. We’ve also talked about the problem definition.

The problem definition process should be a deliberate and thoughtful process of organizing the current knowledge of the problem space, synthesizing information, identifying constraints, and essentially doing any and all feasibility studies that you believe are necessary for your situation.

Problem Definition versus the Product Spec

The next chapter of our course is going to talk about the product spec. This document outlines many of the specs of the product.

The problem definition is not the same thing as a product spec.

The product spec focuses on the product (i.e., the solution) and the details of what should be built into the product in order for it to create value for the consumer.

The problem definition focuses on the opportunity and helps you or your organization answer questions like:

• Should we take on this opportunity
• Can we create a solution to this problem
• Do we understand the critical issues about this opportunity
• Problem Definition Elements

Here are some best practices across various PD methodologies when it comes to Problem Definition. I can’t possibly explain them all — this is The Distillery, after all. Just be aware of them, and you can dig deeper if you think you need to.

Read all of the items in this list with the preface “Now that you have done an initial study of the customer needs and problem space, perhaps you should consider . . . ”

Technical Feasibility — Does the problem space seem like something that you can technically solve (are you trying to cure cancer or otherwise getting in over your head?).

Market Feasibility — Confirm there is a market, which means paying customers, to the extent that you need there to be a market.

Strategic Alignment Check — Confirm that the opportunity is still aligned with the higher-level goals and objectives of your organization.

Scoping — Where a business plan and preliminary technical feasibility assessment are made and a preliminary market assessment for your concept is completed. Pretty much doing those things listed above. 

Market Segmenting — Have we learned anything new and important about the part of the market we are going to be targeting?

Personas — Begin to create customer personas that make the target customer more tangible and fleshed out.

Job To Be Done Summary — Detail out the job to be done, or the many jobs to be done, that you have identified. Include circumstances.

List of Outcomes — have you started to identify the outcomes, which customers will base their evaluation of the product?

Requirements / Must-Have Features — Are there things you know, even this early on, that must be included in your solution?

Constraints — Are there constraints, like costs or speed, that are known constraints at this point?

Regulatory issues — How is da gov’ment or other regulatory agencies gonna try to hold you down?

Reiterating that there is no one size fits all approach to PD, I’m not saying that all of the above activities are essential— different strokes for different folks.

Best Resource for this Problem Definition stuff

I’ve listed it many times, but Steven Haines’ The Product Manager’s Desktop Reference is the best resource for this phase of the PD process.

Developing Products in Half the Time — Don Reinertsen