Let’s Go For a Drive!
Product Management Lessons from Mo Willems’ Award-Winning Children’s Book
Mo Willem’s book, Let’s Go For a Drive!, starts with a great idea. A self-organizing, enthusiastic team dives headfirst into a road trip adventure. Elephant Gerald declares that if this endeavor is to be successful, he and Piggie need a plan. Unfortunately, planning is not Gerald’s strong suit. The result is a lesson anyone involved in software development can learn from.
If you haven’t read the book, go buy it from Mo Willem’s site. (Side note: I do not know Mo, nor am I affiliated with Mo in any way. I’m just a huge fan of his writing, as any toddler parent should be.) While you wait for the book to arrive, take a few minutes to listen to these adorable children read it on YouTube.
“We need a car!”
Gerald and Piggie work hard to gather everything they’ll need for their drive — a map, sunglasses, umbrellas, bags — only to realize that they don’t have the most important thing: a car.
When I first read this book to my daughter, I was working on a registration system for governing bodies of amateur sports organizations. Our lead product manager assured us our work was revolutionary. The product promised to make amateur sports safer, fairer, and more convenient for everyone involved by making any participant’s identity, certifications, and disciplinary actions accessible on the field via a new mobile ID card.
And yet, there was one BIG problem: we couldn’t guarantee that each participant had one and only one card. Our narrow focus on building cards completely ignored what made the cards valuable. Duplicate cards compromised our value promise in a variety of ways:
- A coach with two ID cards wouldn’t know which one included her most recent certification
- A child who got a concussion could still play with the team from the neighboring town
- An athlete’s disciplinary suspension was only tied to one card.
- Or worse, a volunteer removed from a program could use a nickname on next year’s registration. This created a nightmare of paperwork to remove them again.
After launch, we built a deduplication algorithm and workflows to merge members manually, but the damage was already done. We eroded customer trust because we did not tackle the most important needs first.
“Bringing sunglasses on a drive is smart planning.”
How did an “agile,” “product-driven” company fail so spectacularly? Just like Gerald and Piggie, we rushed to produce quick wins and easy features, also known as sunglasses and umbrellas, because we thought users might need them. These milestones allowed us to fill our sprints with easily estimable story points and show continuous progress but did not deliver software that fulfilled the job to be done.
After each demo with the customer, we celebrated with a happy “drive, drive, drivey drive drive” dance and assured ourselves, “Bringing sunglasses on a drive is smart planning.” The customer liked it, didn’t they? These practices drove our teams to become highly efficient feature factories that ultimately did not focus on the right goal.
At one point the problem of duplicates was raised, but by then we had committed to building so many sunglasses, umbrellas, and bags that we did not have time to respond to the needed changes. We stuck to our plan; the date had been contractually negotiated and no one was going to tell thousands of youth athletes that their season was delayed because of a software issue.
What’s your car?
Gerald, Piggie, and my former team learned the hard way that waiting until the end to tackle the biggest risk puts the entire project in jeopardy. Luckily, if we embrace design thinking and product management best practices along with Scrum or other Agile frameworks and methodologies, we can identify our “car” early and prioritize it properly.
The Four Big Risks
Marty Cagan of the Silicon Valley Product Group identifies the Four Big Risks of any software product endeavor as
- Value Risk (Whether customers will buy it or users will choose to use it)
- Usability risk (whether users can figure out how to use it)
- Feasibility risk (whether our engineers can build what we need with the time, skills and technology we have)
- Business viability risk (whether this solution also works for the various aspects of our business)
To alleviate these risks, Marty recommends teams move beyond Lean and Agile in three important ways:
- Tackle the big risks early — especially value risk and business risk
- Figure out solutions collaboratively — engineering, design, and product, working side by side
- Focus on solving problems — it’s not about features or a roadmap; it’s about delivering results
Solve the Right Problem
Once we identify our various risks, how do we verify a specific one is our car? The first and most important step is to ensure you’re solving the right problem. This takes dedicated user research and discovery. All too often, we become enamored with a solution before verifying that it solves a real user pain point (without creating more in the process). For example, the product team wants to build an airplane but all that was needed was a Ford Focus. Sure, both will get you from one place to another, but only one of them is going to get you directly to the grocery store.
You may discover that you have multiple areas of critical risk. Instead of thinking of the car as a single unit, it may be helpful to visualize the various risks as the steering wheel, the engine, or other components. Every vehicle needs an engine, but does your car need a supercharged V8 or a reliable 4 cylinder? Cup holders may not be critical to getting from point A to B, but you may think differently if your customer’s journey always includes a stop for boiling hot coffee.
Discovery and ideation should go through two distinct phases, often called the Double Diamond Model of Design Thinking, each with their own divergent and convergent thought exercises. Yes, this work will increase your team’s lead time. Embrace it. A great workflow diagram or high fidelity prototype can and should be considered a measure of progress on par with working software. Whatever deliverables we can create to vet the usability, desirability, and feasibility of our ideas are worth our time and effort, even if most prototypes are discarded. Sketches are a lot cheaper to create than code.
Evaluate your Potential Solutions
Once you’ve settled on the problem to solve, you can move onto brainstorming solutions. For each solution, identify the outcomes you want to achieve, not just the outputs you will produce. Then, I recommend using the Intercom Acid Test from Intercom on Product Management to determine if your potential solution is worth building. If a potential feature cannot score a yes on every one of these questions, it probably violates one of the 4 Big Risks and you should think twice before building it:
- Does it fit your product vision?
- Will it still matter in 5 years?
- Will everyone benefit from it?
- Will it improve, complement, or innovate on the existing workflow?
- Does it grow the business?
- Will it generate new meaningful engagement?
- If it succeeds, can we support and afford it?
- Can we design it so that reward is greater than effort?
- Can we do it well?
- Can we scope it well?
The questions above will likely whittle down your list quite a bit, but you may still have a large backlog of car parts, sunglasses, and umbrellas that need to be prioritized. There are lots of prioritization techniques, each with their own strengths and flaws. Here are resources on a few of my favorites, in no particular order:
- MoSCoW — Identify and rank your user’s must-have, should-have, could-have, and will not have/wish-for features
- Intercom Feature Audit — Plot features on a grid of how many people use a feature vs how often will they use it
- Anthony Ulwick’s Opportunity Algorithm — Ask customers to quantify on a 1–10 scale the importance of each desired outcome and the degree to which it is currently satisfied, then calculate Opportunity as Importance + (Importance — Satisfaction)
- Dot voting — A simple technique where stakeholders are each given a set number of votes to spend, indicating their thoughts on the importance of a solution or idea
- Buy a Feature — Similar to dot voting, but with a little more teeth. Participants are asked to “spend money” to buy the ideas they find most valuable. The cost of each is typically based on some estimate of the effort required. Depending on your rules of engagement, participants may be able to pool their money or only allowed to spend it selfishly.
Any of these prioritization approaches should leave you with a strong foundation to order your Product Backlog based on what will drive the most value for your users. Once you have that initial order, make sure to vet your results with a cross-functional team of stakeholders and customer advocates to verify you’re truly putting your user needs first, not just prioritizing perceived quick wins. If your product backlog is especially deep, this vetting process needs to happen repeatedly as you learn more about your customer needs and your market changes. If you can master that, you’ll be happily driving in no time.