Intelligent Design, it’s Not Just for Religion

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:

  1. Whoever makes the most articulate case for their opinion
  2. 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.


Steve Johnson at Pragmatic Marketing disagrees with me about the ID Method. In his article On Reqs and Specs, he writes:

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.

Previous Post Next Post


  • Reply Stewart Rogers October 7, 2006 at 10:14 am

    Hi, I must admit I am a little confused about this gap between requirements and solution. Is this not an HR gap / development skill-set issue? Is the Product Manager reponsible for usability? Is product design one of our job requirements? I must admit, I know nothing about product design. I know what I like in a UI but that is just my opinion. Should design not correspond to your personas?

  • Reply Paul October 9, 2006 at 4:25 pm

    My view is that the PM is the ultimate arbiter of the product that leaves the factory. In the traditional PM approach we have learned through Pragmatic (which, BTW, I believe is awesome), we are taught that through well written requirements, use cases, and personas the correct product will develop. I think it gets you 90-95% of the way there. I think the Intelligent Design PM needs to help push the last 5%. I’ll use 2 examples, one from outside my industry and one from my daily life.

    First the video game industry. Shigeru Miyamoto was the developer of the original “Legend of Zelda” video game for Nintendo. His title was designer but I believe he was what we would call a Product Manager today (he had no programming experience when joining Nintendo). In the hyper-competitive gaming industry, he has been responsible for hits from Zelda to Mario to Donkey Kong. I believe he is an ID PM. ID because he knows what people want beyond the requirements – a passion that is embedded in the product deeper than any requirement can reach, and he knows what people do NOT want (another shoot ’em up).

    From my side, high-end consumer electronics, there are definitely non-functional requirements that can’t be stated, and can’t be constrained out. There is an unstated passion, or level of completeness that I can tell when I look at a final product if it is going to resonate with our customers.

    So Yes, it’s a skill set/HR issue. Yes, I believe the PM is responsible for usability just as much as any other part of the product. We don’t need to be UI experts but we need to look logically at a UI (or any other part of the product) and say “does that WORK for our market?” Since we’re ultimately responsible for the product, I see it as the purview of the PM to kick back any aspect of the product to the functional group that made it with instructions to rework based on the PM’s experience living in the market, e.g. “You don’t have to be a cook to tell if the food is spoiled.”

  • Reply Stewart Rogers October 10, 2006 at 4:00 pm

    OK. Fair enough as long as we answer “does that WORK for our market? with facts and not opinions.

  • Reply Dany March 12, 2009 at 2:21 pm

    Is there a way to put this on a trial basis?

  • Leave a Reply