There are three predominant modes of bringing products, software, and services to the market today. The first is the “Extension Method,” which is used at commodity based companies. The second is what I call the “Divination Method,” which is used by most startups by people who believe they have cracked the code of their Market. The third is the traditional Product Management Method, which I see more and more companies of all sizes adopting for its advantages in product accuracy. All three methods have their advantages and overhead, but I believe it is time for a discussion of the merits of each, and propose a new method – the “Intelligent Designer Method.”
The Extension Method.
Extension Method is what I refer to as the method that commodity companies use to “innovate.” At Dell, for example, there is a lot of Extension Method Product Management. Does going from a 1.0 Ghz processor to a 1.5 Ghz processor solve a problem? Yes, for .001% of the World it might. But there isn’t a lot of thought put into moving the bar in a commodity market; buyers buy on specs, specs get bumped every 3 months, rinse, repeat.
Microsoft is falling into the Extension Method with the Office suite. Yes, there is still some innovation, but the majority of features are unused, contributing to bloat and feature fatigue. Users buy Office on momentum (it’s what people know), and as part of their natural refresh cycles, not because of some new feature that the problem solves. Fortunately, MS is starting to innovate in the UI area, which should drag them out of this cycle.
The advantage to the Extension Method is that it is very fast and has very low overhead. Naturally, anyone buying a 1 Ghz processor would want a faster one, especially at a lower price. So keep the upgrade cycle spinning!
The disadvantage to the Extension Method is eventually you hit a wall. In the case of processors that wall is not price or speed, but need. People want a faster processor, but there isn’t a need for it for 90% of the population. Most people just check email and browse the web.
The Divination Method
You usually see this in early stage startups, from founders or engineers who believe they’ve “cracked the code” of the market and know exactly what products the market needs. You’ll know you’re at a Divination Method company when you start whiteboarding the product first, before you’ve done any research as to what the product could or should be (note that this is different than the Backwards Working Trick, where you start with the problem and work to the product).
There are problems with Divination. First, the longer the Diviner has been in the company and out of the Market, the more potential he/she has to be out of touch with what people need. Second, Diviners are almost always power users, and their products reflect their advanced level. Third, Diviners usually have big egos are in are in C-level roles surrounded by people who are too afraid for their jobs to challenge them, putting them in a dangerous ego-feedback loop that can lead to thoughts that they know what they’re doing better than anyone in the World. Yikes.
Be very careful with Diviners. My usual tact is to gently introduce market data that backs up their points, and gradually bring in market data that doesn’t reflect their opinions. It’s harder for them to discount the data you’ve gathered if they’ve already accepted it when it backed them up. Over time, you can push back harder and harder with the data in hand without fear. However if you push back hard the first time without data, you are expressing a PM’s worst enemy: an opinion. Opinions are worthless. Everyone around the table has an opinion. As a PM you have to bring facts. In lieu of facts, people will win product arguments in one of two ways:
- Whoever makes the most articulate case for their opinion
- Whoever has the highest rank
Neither is ideal.
Traditional Product Management
If you gather Market data, compile problems, research competitors, write requirements into MRDs, put together business cases, and guide your Executives along a logical decision making path, then you are probably practicing the Traditional Product Management Method (TPMM).
The problem with TPMM is that we can gather problems, and we can spell out requirements, but there is a gap between the requirement and the solution. Some of that gap can be closed by writing strong, tight requirements, having a good relationship with your Development team and Architect, and so on. But the gap can still exist, most especially in the area of the product’s design.
The Intelligent Designer Method
The ID Method I propose builds on top of the traditional product management method. It’s not enough anymore to build requirements, use cases, and grey screens. PMs must take a more active role in the overall design of the product. If you are lucky enough to have a product designer, or your architect handles this role, than you may not have to take on the Intelligent Designer Method.
Take my Scientific Atlanta cable box. It probably meets all the requirements that the Product Manager laid out for it. It tunes all my digital cable channels effectively. It has a DVR function and I have several options for how to record and view shows. But it was obviously designed by the hands of an Engineer, not someone who faced the Customer. I forgive these faults and learn to work around them because I’ve come to expect faults in consumer electronics (especially from the cable company, grrrr ). Would a Product Manager practicing Intelligent Design let this product out the door?
The ID Method means that the Product Manager must take an active role in the product design and UI. If you have a designer, don’t do their job, let them add value. But only the PM is dedicated to studying the market and knows what designs will fly and what won’t. The PM should validate the designer’s design and push beyond the requirements to create a more compeling product.
For example: Method soap doesn’t get your hands any cleaner than other soaps. But the design of the bottle turned soap into a statement in style. The PM and designer of the Method packaging knew their target market, knew that an innovative, eye-catching, theme was needed, and went beyond the requirements (kills bacteria and smells good) to create a cool product.
The danger with ID is that if you start with the product in mind, you’ve cut yourself off from potential solutions, and undermined Development. ID is about injecting yourself and the knowledge of the market into the design process in an effective way.
Not every company can make design part of their core competency. Intelligent Design Method is my plea to PMs to continue to push beyond the functional requirements and realize that by taking the design aspect of their product to heart, you can redefine success.
The primary role of the product manager is to be the “messenger of the market” (reference: Role of Product Management), and we must not take on additional tasks until that primary one is completed. Yet product managers frequently attend design meetings. Why? What value do they add? If product managers have time for design meetings, it had better be after they have completed their on-site visits with their market segment.
Besides, product management attending design meetings is not about getting better designed products; it’s about sharing blame for poor design. “What do you mean you don’t like it? You were there when we designed it!?!?!” If product managers are creating the design, what value is development providing? Coding? If that’s all, perhaps we should just fire all the developers and outsource to India or Ireland or someplace where at least they will code to our design. That is, we’ll get exactly what we asked for without the developer’s editorial license.
I have to respectfully disagree with Steve on this point. I do believe a PM can add value to the design discussion by educating the design team on how important design is to the customer, what the customer looks for in the “experience” of the product, and how the PM expects the customer to use the product.