What Not to Build

All this while, doing market research, if you have been hunting answers for the "what-the-customer-wants" question, I can give you the answer. Here it comes. The envelope please...

Your customer wants a superior product that delivers unique benefits and excellent value.

Simple, huh? Let’s look at the word value.
Value is a function of the benefits, features, and quality that are built into a product versus the price of the product. The more benefits, features, and quality a product can deliver at a low (or reasonable) price, the more value the product has.

“… the more value a product has” Actually, that perfectly-reasonable sounding phrase is misleading. A product does not so much have value as the consumer perceives value in that product. It would be quite convenient if you could simply pour value into a product as you pour a few litres of oil into your car. But value is not an absolute quantity. It is relative. It is a perception.

The fact is, no one knows value. Only the customer knows it. (At least he knows it sometimes and about some things. It is actually more a perception, a feeling, a sense.)

A nice-PM understands that during market research, it is his job to find out what the customer defines as value in a particular product or a class of product. Some questions that our nice-PM needs to ask that relate most directly to his products value would be:
1. What do you look for in product X?
2. What criteria go into making your investment decision?
3. How important is performance and robustness to you?
4. How much are you willing to pay for high performance and robustness?
5. What tradeoffs are you willing to make to save money? What features or levels of performance are you willing to live with to save money?

Most of a Product Manager's business life is spent in avoiding problems. However, in market research he has to eagerly seek out problems. Problems are very strong motivators of consumer purchases, and customer buy-in's. People will buy something they believe will solve a problem that afflicts them.

Problem detection studies are often quantitative surveys designed to define problems in a category and then rank them based on intensity (How bothersome is the problem), frequency (How of the does the problem occur), duration (How long does the problem last), and preemptibility (What is the extent to which currently available products can solve this problem).

To discover needs and ferret out problems, a nice PM conducts surveys and asks questions. He may also arrange to actually watch a process, whether that process is machining a precision part, mowing the lawn, opening a bank account, or designing a mobile application. By studying the process, he identifies gaps, needs and more importantly, problems!

There is a catch here, instead of looking for ways to arrange work processes so that they are more efficient, our nice PM is looking for ideas about new products that will appeal to consumers by making tasks or processes easier, more efficient, more pleasant, more profitable and so on.

Talking of task and process observations, they should be combined with questions:

1. Ask the potential customer to list all the tasks or steps involved in this project.
2. Ask him to rate the steps from pleasant to unpleasant.
3. Ask why he finds a given step pleasant or unpleasant.
4. Ask if, why and how he would would like the step, task, or process changed.

Some product managers are control freak, and some are too cautious. Those are bad fishes in my opinion. Teams that work in agile style, developing new products must be working close with the customer.

There could be instances where a team is newly formed and folks do not have much know-how about the attitude, way of life etc. of customers. The bad fish PM if given this situation does the following:

1. Runs short sprints, like 1 week. And here is the bad part - he claims that since he doesn't have trust in the team, he can't afford to lose control.

2. Although the team has good and proven experience in software engineering (although not in the current domain), they are NOT allowed to talk to customers.

3. All requests from customers come via the PM. (ok, this could be fair). If developers have doubts or questions, they have to ask the PM, and he decides when and how to take those queries to customers.

4. He yells in some meetings "I know the customer, I know what he wants! Do what I say."

5. No single soul in the development team, yes no one, knows who is the customer. Forget about what customers do and where they are!

6. PM arranges a face to face workshop with customers and does not take any developers/testers along.

Do you think this team (which is composed of experienced guys who could be new to the system) can ever grow, emerge and delight the customer?

Speed is increasingly of the essence in new product development. The idea is to get to market fast. But how do you "do it right" and "do it fast"? Well, just because you might do something slowly doesn't mean you'll do it right, and it's also true that speedy execution does not preclude high quality of execution. No two ways about it, though, it does make the task more challenging.

The single most effective way to speed up the process is not to make mistakes. Instead of cutting corners, build in quality at every step, so that you "do it right the first time" and don't have to waste time doing it over again.

Product managers should invest a lot of time in defining the new product at the outset, so that everyone doesn't squander time on unfocused and unnecessary activities.

Let's not run a relay race. Ever since Henry Ford made the assembly line practical, businesses have been obsessed with sequential processing: do this, finish it, then do this, finish it, then go on to this and so on. To whatever degree possible, you should try to abandon sequential processing for parallel processing. Divide the task at hand to several parallel steps. And of-course make sure you maintain constant intercommunication.

Through clear definition of corporate goals and strategic plan, you should prioritize the proposed new activities. Which ones are important to work on now? Which can be back-burnered? Which can be scrapped? If need be, make hard choices, and then, get set to work on them.

Speed is important in product development, but carelessness is unforgivable. It is not unforgivable just for some highflauntin moral reason, but because customers will not forgive products that are flawed in design or in quality. Most people spend much of their lives trying not to look like fools. Your customers are no different. They won't take a chance on a new product that has a flawed reputation.

Believe me, killing your own product is the most painful task you can ever be "told" to do. Sometimes, we are in so much love with what we build, that we tend to forget the ecosystem around it. This could be a BLUNDER for any product manager.

First line of a PM's job description surely reads - "Define the right product to build". And when this definition is changed in such a drastic way that closing current development makes more sense, more often than not, teams start to get frustrated and fidgety. What others may not understand (and the PM must) is that "being in business" is more important and critical than being on the cutting edge of technology or building beautiful products.

For a team, to collectively enter the comfortable "I-know-enough" zone is pretty common. I have seen some products getting closed / realigned so late and with such convincing reasons that at times I start to wonder why not earlier! Things could get tricky when there is a trade-off between making early decisions and minimizing risks. How to handle this is not just a strategic stunt but also a challenge for PMs.

So what could be the reasons that could lead to shelving of products?
1. Technological imbalance:
Could be caused by inventions, acquisitions, and even by slow development progress.

2. Organization wide priority shuffle.
Tying your product with the mainstream value chain of your business is crucial. And with every
adjustment in this chain, products' priorities are often realigned.

3. Turbulence in the ecosystem
What do you do when you find out that your potential customers will not be in business by the time you are ready to ship? Stop. Think.
What do you do when you find out that your competitors are marching at a velocity that is several times yours? Think. Stop.

and last but not the least
4. Dearth of dollars!
Sponsor(s) could lose the confidence or money and may pull out.

Do you know of more reasons?
And yes, my big question is still open - should you "love" your product?

If you are starting on some new project, and your role needs you to define and prioritize requirements for a product, taking the "Breadth-First Approach" makes a lot of sense.