John Cutler on Product Management Lessons Learned

Key product management lessons learned extracted from two blog posts by John P. Cutler: “50 Things I’ve Learned About Product Management” and “Feedback Loops and Done.“

John Cutler on Product Management Lessons Learned

John P. Cutler (@johncutlefish) | blog | YouTube Channel) writes extensively and insightfully on product management and user experience and this post uses key insights from two of his blog posts, “50 Things I’ve Learned About Product Management” and “Feedback Loops and Done,” as points of departure for advice to bootstrapping entrepreneurs–and intrapreneur and corporate change agents who face many of the same challenges as the bootstrappers and can be their partner in using their product to create value.

Note: the diagram and everything in quotes are John Cutler’s words. The commentary is mine and he may or may not agree with any or all of it.

Sense & Respond + Resource Plan + Build-Measure-Learn + OODA

Cutler uses this diagram at the top of “Feedback Loops and Done” but although he makes a number of other points he never really explains it in the blog post. He did post an explanation for “David K.” on his YouTube channel and what follows is my understanding of his synthesis of “Sense and Respond” with “Plan-Do-Check-Act” and “Build-Measure-Learn.” It’s been clear to me for some time that we should say “Measure-Learn-Build” but Cutler’s synthesis is a more useful restatement.

Product management–even with continuous delivery and continuous discovery–is fundamentally about managing a sense and respond process. Identifying opportunities, shepherding the evolution of the product toward them, and verifying that the customer got value from adopting and using them. Although he draws the diagram as if you start with planning and resource allocation, the reality is that you start with careful observation and measurement. If past experience–including retrospectives and post project assessments–and customer insights–including both direct observation and customer interviews–do not inform your planning process you need to start there. The diagram should be rotated 180 degrees so that the “sense” half is on top.

Sense: everything related to understanding what is going on inside your organization and team, and how customers make sense of and use your product.
- Measure: this includes careful observation, conversations with product team members and anyone who interacts with prospects and customers, as well as any data collected from product use including bug reports, lost benchmarks, and other prospect requests to sales.
  Key challenge: organizing the data into information and the anecdotes into narratives that the entire team or organization can understand, critique, and learn from
  - precursor: Instrument
    You can only measure what you have instrumented so the first step may be to upgrade both your discovery efforts (more time and effort devoted to customer interviews and gathering feedback from sales and support) and how well you have instrumented the product to collect relevant information.
    Key challenge: it’s very difficult in most cases to directly measure the value that your product creates from user action without developing a model that maps behavior to impact.
- Learn: the result is a working consensus at team level (in a startup, at executive level in an enterprise) as to how customers use and want to use the product and where the gaps are.
  Key challenge: building a working consensus requires trust and shared situational awareness, both of which take time to develop at a team and organizational level. If you are working on a technology product that requires different types of experts to collaborate then there is additional time needed to develop an appreciation for different perspectives and terminology.
  - precursor: Extract Insights [blocker] an insight is a deep understanding for the true nature of a situation. It requires not only an understanding of the personal and interpersonal issues but the economics and incentives that the customer’s business model imposes on their approach to hiring your product to do a job for them.
    Blocker: Cutler calls out a lack of insight as a key blocker in the product management process and I think it’s a critical one. You can scale your efforts to compensate for a lack of resources–and to some extent a lack of expertise or requisite skills–but your understanding of the customer’s situation and needs is flawed your product will not create value for them.
    Key challenge: a willingness to be surprised, to appreciate the customer situation and need, and to engage in conversation and negotiation about what’s possible and useful in the next iteration of the product.
Respond: everything related to developing and delivering a new product for customer evaluation and use as well as fixing identified problems in current version where they are a priority.
- Resource/Plan [blocker] Cutler identifies the “planning” step as missing from “Build-Measure-Learn” and I agree. Understanding what resources you have on the team, and what additional ones you can marshal to your efforts, is a critical step to take before starting to build.
  Key Challenge: a willingness to budget for all of the normal setbacks and missteps involved in any innovation and to adjust the schedule accordingly.
  - precursor: Filter: this is really triage, determining where you can make a difference with this next release. It does not mean abandoning the vision but adjusting your next milestone to the critical business issues your customers and prospects are facing now and letting go of not only the “nice to have” but the “should have” features to ensure the musts are delivered.
    Key Challenge: it’s not a real plan until everyone is a little unsatisfied.
- Build: this is a complex step for innovative products and may involve the use of simulation and a sequence of prototypes just to ensure feasibility.
  Key challenge: understanding requirements, explicit and implicit, and the risks involved in new methods, building blocks, and technologies.
  - precursor: Orient: Cutler takes this from “orient’ in Boyd’s OODA loop and suggests that a plan should build on cultural strengths, organizational know-how (which may be tacit), and team experience and expertise.
    Key Challenge: a lack of appreciation for the difficulties of innovation (“how hard could it be?”) and a mistaken belief that you can treat the development team as interchangeable parts when in reality they have strengths and weaknesses at an individual and a team level.

The Far/Close question: if key folks involved in Measure-Learn-Plan-Build are all on the team or working closely with the team you will move the fastest. To the extent that one step in the process is distant or disconnected it’s likely to be a source of miscommunication and handoff problems. This is the “Conway’s Law” factor where communication problems in the development organization appear as problems in the product architecture and function. Poor communication hinders the co-evolution of the product and the organization that produces, sells, and supports it.

Plan For Several Small Attempts You Can Survive

1. You are wrong more often than you are right. The trick is getting a couple shots at solving the problem.
John Cutler in “50 Things I’ve Learned About Product Management”

For new initiatives that have two or three aspects that need to coordinate we plan for three tries and a polishing step at the end. Nothing new ever works: if it has to work the first time you are well served to explore multiple approaches in parallel and see if you can adapt as much of a proven approach as possible.

A Workable Plan of Action Includes Everyone’s Contribution

9. Someone on your team has a better idea. Would you know?
John Cutler in “50 Things I’ve Learned About Product Management”

Some of the handy phrases:

I need your perspective on this draft
What are we missing?
If it’s six months from now and it didn’t work why do you think that would be?

Successful Product Managers are Investigative Reporters

12. Show—with data, stories, and examples—don’t tell.
John Cutler in “50 Things I’ve Learned About Product Management”

We have seen the following situation several times: a new sales, marketing, or product management person is added to a startup team and gets ignored–because they are offering opinions. Perhaps it’s actually well-informed judgement backed by prior experience. But until they offer the proof points behind their recommendations–customer quotes, customer data, direct observation of customer situation, logs of customer activity–they find it difficult. You have to be the “lens in the beam” provided a focus and refinement on customer and prospect words and actions.

Aim Ahead of the Competition–They Are Not Standing Still For Your Next Release

14. You tend to go where you look. If you look too hard at the competition you’ll go towards them, instead of towards point ahead of them.
John Cutler in “50 Things I’ve Learned About Product Management”

I watched this approach cripple the high-end router group at Cisco after Juniper entered the market. They aimed to get a product out quickly that would match and learned that complex products cannot get to market quickly and the competition does not stand still. Where you can stumble on this is to overshoot in one dimension that already satisfies a customer and ignore emerging buying criteria. For example: do you care if your laptop runs 30% faster or has 30% more battery life? Obviously. it depends upon where you are on both curves and the trade-off is not linear between the two dimensions but it’s always worth considering what would happen if you would concede one race to win another.

The Heroic Must Become Routine

19. When heroics become the norm, then only heroics will generate reasonable results.
John Cutler in “50 Things I’ve Learned About Product Management”

A startup requires heroics to get moving: the challenge is to create flexible process as quickly as possible to preserve your capability for heroics when it’s truly needed.

Address Problems Immediately and Always Look In the Mirror First When Doing Root Cause Analysis

20. Before you send that canary-in-the-coalmine email, keep a journal for a week and reflect.
John Cutler in “50 Things I’ve Learned About Product Management”

I would say keep a journal at all times and address issues as they come up. Don’t save up problems and hurt feelings like so many trading stamps you can exchange for an angry resignation email. When I was younger I always felt I was held back by the people around me, after a couple of jobs I began to realize I was the common factor in most of my recurring problems.

If The Customer Has Not Used the Feature and Given Feedback, Don’t Count it as Shipped.

24. All bets are off until someone is trying to use the feature with their data, in their environment, in their day to day work. You have to leave time to iterate based on that feedback.
John Cutler in “50 Things I’ve Learned About Product Management”

We always encourage our clients to understand what the “value realization step” is with their product. If you are not careful you define installed software or paid for it vs. customer demonstrated value to manager and peers so that follow on orders are now possible. As a rule of thumb, you can capture between 10% and 40% of the real value compared to the status quo of your solution. Getting to where the rubber meets the road to be able to measure that will ultimately drive your pricing which is how you capture some of the value that you offer customers.

Product Management is Air-Sea Rescue: Go To Where the Issues Are

32. Spend time in the support queue, jump on customer success calls, and try to close some deals.
John Cutler in “50 Things I’ve Learned About Product Management”

When I became a product manager for router software at Cisco–one of many I must quickly add–I was new to the role and my manager suggested that I look at it as an “air sea rescue” function. I had to go to where the problems were and should not assume that if no one was complaining everything was copacetic. Product management has responsibility for the roadmap but if you don’t have the trust of everyone you need to sell and support it then it will remain a document.

The Status Quo is Your Most Experienced and Respected Competitor

33. In most cases, your biggest competition is the status quo. Same goes internally.
John Cutler in “50 Things I’ve Learned About Product Management”

The status quo is always part of the benchmark, even if the prospect trying to choose between two unproven–or barely proven–solutions. An innovative product needs to be as compatible possible with current offerings: this is why lightbulbs were rated for “candlepower” and engines for “horsepower” and early appliances didn’t come with plugs but screwed into light sockets (many people had only installed lighting and only had screw sockets for a new appliance to draw electricity from). Corporate change agents succeed by appealing to established cultural values to effect change, the less you are trying change people’s values and cognitive model of the job to be done the more successful you will be.

Listen For What You Are Not Hearing

34. The users that have given up on you aren’t replying to your NPS (Net Promoter Score) survey.
John Cutler in “50 Things I’ve Learned About Product Management”

Customer silence is not often satisfaction: if they are not calling the hotline it could be they have given up on getting help from you. Instead of running an NPS survey, make it easy for customers to offer case studies and referrals. If you have few of either figure out why.

M	T	W	T	F	S	S
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31

John Cutler on Product Management Lessons Learned