The Art and Science of Product Management

What a great idea. I hope this takes off.

Axiom 11: Engineers will build stuff with or without you.

I’ve discovered something in the past 20+ years building software. Engineers write code. That’s what they do. They will write code whether they have a strategy, plan, backlog, or anything else. If there is a vacuum of vision or definition, they don’t stop writing code, they write the code they want to write. It is like high volume flowing water, or electrical current, or any other force that can be channeled but not stopped. If their force is focused and guided it can produce great things.

A follow on to this earth-shattering insight is that an engineering team will always do the amount of work that they have capacity to do. This may seem obvious but I’m surprised at how often this is overlooked by companies that have standing teams. Imagine for example that you have a long-standing team of 6 engineers focused on building some layer of your stack. Even after they have completed building a sufficient widget, they will continue to expend 6 engineers worth of effort on that thing. It will grow in complexity. It will get refactored. The more they write, the more they must maintain. They will make major and minor performance improvements. Most of these will be meaningless to the business overall but they will not stop writing code.

The natural outcome of this phenomenon is that job 1 for a product manager is to never leave an engineering team without clear direction. In saying that I don’t mean to suggest that engineers aren’t capable of creating great things on their own. Nor am I suggesting that every line of code needs to be guided by a product manager. I’m emphasizing the value of clear direction for aligning resources and keeping teams motivated.

Checkout the complete list: 11 Axioms of Product Management

Axiom 10: Customers are NOT good for solution discovery and creating roadmaps

If you ask a customer what feature they would like you to add to your product or ask them what they would like your roadmap to be, most of them will respond with their feature request of the day. This information is not invaluable, it is just incomplete and potentially dangerous (thus the importance of Axiom 9).

There are a few fundamental issues here. First, going to customers for solution discovery may tell you what they want but it won’t tell you why they want it. You are at risk of missing the underlying drivers and subtleties that will make the solution successful for them and your other customers. Second, the thing they say they want often isn’t the thing they need or at least not the thing they need most. Third, you will often miss an opportunity to solve the macro problems (in other words deliver big value) and only play around the fringes with micro problems - symptoms of the underlying issues. Fourth, and most important, you will miss the opportunity to understand what will provide real value to the customer (see Axioms 1, 2 and 3).

So how do you do solution discovery? The real question is “What do I do before solution discovery?”

  1. Form a small team comprised of product management, experience design, and perhaps a lead engineer.
  2. Work as a team to attain and document a detailed understanding of the problems your target customers are facing.
  3. Validate these problems with your customers. This is best done in story form. Tell them the story of a day in their life. At the end of the story they should be resonating with the pain described and ask if you’ve been spying on them.
  4. Prioritize the problems. A great approach to this is to run an Innovation Game called Buy a Feature. Substitute future features for current problems. The output of this exercise should provide insight into the relative value of solving each problem.
  5. Identify and articulate the value that would be created by solving the validated problems. Important: you are not articulating how to solve problems, simply describing what the world would be like if you could make the problem go away.
  6. Brainstorm what would be required to deliver the value you described in step 5. (You just started solution discovery). Iterate on this.
  7. Validate the proposed solution with your customers. This is also best done in story form. Tell them the story of a day in their life with this new solution. At the end of the story they should resonate with the solution and be ready to staple money to your hand.

There is a great deal that could be said about various methodologies and subtleties to the 7 steps above. If steps 1-5 are performed, step 6 tends to be greatly simplified. This is the pattern that I’ve seen succeed. What experience have you had? How would you improve this approach?

Checkout the complete list: 11 Axioms of Product Management

Have you ever discovered a cattle mark?
Samuel Holmes is one of my 5th Great Grandpas. My 15 yr old daughter and I stumbled across his cattle mark while scrolling through a microfilm in the Family History Library in SLC this past weekend. We’re thinking about making t-shirts from his cattle mark.

Have you ever discovered a cattle mark?

Samuel Holmes is one of my 5th Great Grandpas. My 15 yr old daughter and I stumbled across his cattle mark while scrolling through a microfilm in the Family History Library in SLC this past weekend. We’re thinking about making t-shirts from his cattle mark.

Love this concept and the general trend around mobile devices managing an internet of things.

The Greenbox platform uses data from the cloud to offer advice and automate tasks for those with outdoor gardens.


This was an excellent read. Great perspective on how to excel in product management.

Axiom 9: Customers are good for problem discovery, solution validation, and paying the bills

Wouldn’t it be great if we could simply go to our customers and ask them what we should build? Unfortunately, that approach rarely pans out. It is a rare customer that comes up with good solutions to the problems they are experiencing. Especially a solution that makes sense throughout your product and across your customer base. You can always tell when a product has been managed by being driven by what the customer is asking for rather than understanding the underlying need the customer is communicating and solving the problem. The product will have many features that aren’t cohesive and are often somewhat redundant with each other. It will look and feel like something that has layer upon layer of un-rationalized evolution.

howl's moving castle in asahikawa

Product managers get a lot of pressure from the sales force, executives, and customers to just bolt on custom capabilities to help sell the next big deal or pacify an unhappy account. Responding to these demands is real and needful. How you respond is the difference between a sustainable, elegant product and a huge mess.

Fundamentally customers are most useful for 3 things: problem discovery, solution validation, and paying the bills. When we allow customers to play the role of solution designer, we get in trouble. Not because they aren’t smart, but because their perspective tends to be specific to their business. It may be even as narrow as their role in their part of their business.

When a customer, sales person, or executive comes to you and demands a widget, you MUST somehow turn the conversation into problem discovery rather than solution design. One way to do this is to help them realize that you want to nail this feature for them and the best way for you to nail the feature is to understand the problem more deeply.

After you understand the core problems that resulted in the feature request, the next step is to verify your understanding of the problem with the customer (customers are very good in this role). From there it should be typical product management, rationalize the problem into your problem set, explore potential solutions and propose the alternate solution back to the customer (and many other customers) for validation, then incorporate it into the product.

There’s a difference between listening to the customer and solving their problems.

Checkout the complete list: 11 Axioms of Product Management

Right-time Marketing: Serendipity or Savvy?

I had a great marketing experience this past Friday. It was so good, I’m left wondering if it was serendipity or savvy.

At about 2:30 Friday afternoon I had a little free time so I went to one of my favorite websites for discount sporting goods. I’m always in the market for a good deal on trail running shoes. As I looked around the home page I noticed something new. They had carved out some prime real estate to generate additional revenue through 3rd party display ads. I was pleasantly surprised to see the following ads from Westin Hotels and Delta Airlines.


You see Thursday morning I checked out of a Westin Hotel in San Francisco. Friday morning I had two e-mails from Westin in my inbox. The first was a thank you for staying email. Well-done Westin. The second was an offer for a discounted stay in a Westin resort in Cancun. I clicked through to learn more about the offer (it was a really good deal). I mentally basked in the sun on beautiful beaches for a few minutes. With the smell of the ocean in my mind, I went to to see how much airfare would cost to Cancun. When I saw the ads from Westin and Delta together it felt like a perfectly executed campaign. Excellent right-time marketing.

So was this just serendipity or is it savvy marketing? I’d have to ask the team at Starwood and Delta to know for sure. Let’s assume that these guys are really savvy digital marketers. How would they pull it off?

To start with, Starwood and Delta have a program that gives me Delta Skymiles for staying in Starwood Hotels. This also let’s both Delta and Starwood associate me with my rewards account number. All you would need is a little coordination and the rich capabilities of Adobe Marketing Cloud and you’ve got a killer campaign. Use Adobe Analytics Premium to pull together data about my behavior patterns as a customer and put me in a segment of frequent travelers that were recently someplace warm on business and returned to someplace cold. Continue to use Analytics throughout the campaign to track user behavior. Add to that Adobe Campaign for email marketing. Pull Adobe Experience Manager into the mix to deliver excellent website experiences at Starwood and Delta. Finish it off with Adobe Target to optimize my onsite experience, and Adobe Media Optimizer for display ad re-targeting. That’s how you do savvy marketing.

Axiom 8: Problem Discovery Comes First

Problem discovery comes first. Period. Well — usually. There are a few notable exceptions but it is hard to distinguish those from luck.

Any good product person worth their salt can stand up and preach a southern revival-style sermon on the absolute necessity of understanding the problems of the target customer before trying to create a solution. This wisdom seems readily accepted and yet in most organizations I’ve worked with it is often set aside in pursuit of delivering the solution. STOP! Don’t do that.

Stopalicious 2

Take time to understand and validate the problem sets your target customers are dealing with. This means getting out of the office and becoming embedded with your customers. Direct observation of customers doing their work will provide the highest fidelity understanding of their problems. Creating composite maps of observations across multiple customers leads to deep understanding. You know you’ve nailed your understanding of the problem set when you describe to a customer (that you have not observed) what their world is like and the pain they feel with such clarity that they wonder if you’ve set up spy cams in their office.

Beware! Board rooms are the enemy of problem discovery. That is unless the natural habitat of the problem you’re trying to discover is a conference room.  Most product managers are dependent on their sales force to connect them to customers they might observe. Sales people are wonderful. They make us money. They also have ulterior motives and dwell in conference rooms.  In most cases you’ll need to circumvent your sales force or put heavy restraints on them to arrange proper settings for direct observation. Insist that the sales team be left behind.

While direct observation provides high fidelity it is also the most expensive type of research. There are times where direct observation is incredibly difficult. For example, I once did research on family communication patterns. We decided not to go into the homes of strangers and observe them 24 X 7. This would have been challenging in many ways including drastically skewing the natural flow of communication. When direct observation is not feasible, the next best approach is the post-facto interview. Get them talking about the last time they did the thing you’re interested in. Have them speak specifically about that instance even if they think it was not representative of their overall experience. Don’t let them generalize. (Note to self. Write a blog post on the art of post-facto interviews). Create composite charts of the discoveries from these post-facto interviews as you would with direct observation. Composite charts across many interviews will show you what really is normal.

Unfortunately there aren’t any other good ways beyond direct observation and post-facto interviews to do problem discovery. (If you’re aware of something please share.)

Problem discovery is essential in new product initiatives but is also helpful throughout the product life cycle. Imagine any product that you work with that seems off the rails. Perhaps sales are dipping or perhaps key metrics like net promoter scores or customer satisfaction ratings are low. If you step back for a moment you might discover that the team has lost focus on the problems to be solved. They might not have a sufficiently deep understanding of the problem set or the problems set may have evolved. In these cases, going back to an analysis of the problems the customers are experiencing will almost always lead to insight on what needs to happen to correct course.

If you’re wondering where to go or how to take your product to the next level the answer probably lies in getting back to problem discovery. Go and observe.

Checkout the complete list: 11 Axioms of Product Management