Product managers have a dangerous role because of one oft-missed truth: Decisions about what to build are far more costly than most teams realize.
Decisions about what to build are far more costly than most teams realize. (tweet this)
The cost of saying yes
To start, humans are horrible at predicting the future. We like to pretend we know how long something will take, or how much it will cost, or what impact it will have … but we don’t. Let’s stop pretending.
Most people rely on opinions to predict the future. These are typically random in terms of their likelihood to succeed.
Good teams use past data to predict the future. This is better than opinion alone, but still often wrong. When you’re dealing with the new and different, past data isn’t an indication of how something new will perform.
So how do you deal with predicting the future? The best teams predict a little bit at a time and then verify.
Long term visioning isn’t bad. Too many people assume that agile means no planning. That’s junk. You have to know where you’re headed. But the typical pitfall is to spend way too much time planning for a future that doesn’t exist. It’s a trap to plan too much detail too far out. It feels productive because you’re doing something. But as soon as anything changes, you can take all of that spent time and throw it in the trash.
Some teams spend a lot of time thinking about features that won’t get built for 6+ months. And by that time everything will change (ex. COVID19).
If you say ‘yes’ to planning too far out, you are very likely to waste that time.
But that isn’t all. Even the things you are building today have great cost associated with them.
The iceberg
Kris Gale (VP of engineering at Yammer) shares a story about how he built a feature in a single hour, but over time spent 40+ hours supporting it:
This probably took me an hour to implement, test and deploy back in early 2008. I have easily spent 40 hours of my time — and, necessarily, 40 hours of others’ time — over the intervening 5 years explaining this feature and its justification. That’s a 40x communications overhead just to carry the feature, even before we consider its impact on people once they get into the code.
There are tons of hidden costs when building features. You see the ‘half-day to build’. What you don’t see is:
- QA + Debugging
- Deploying
- Internal Communication + Meetings
- Marketing
- Rework
- Support + Maintenance
This means that prioritization decisions are easily 10x more costly than they may appear. The importance of knowing if what you’re building is actually working cannot be overstated.
How do you know if something you built has worked?
A pervasive issue with most teams is measuring impact. Measuring takes time and many teams lack the maturity and discipline to measure and iterate.
This ends up killing startups and slowing enterprise teams to a crawl in terms of making meaningful progress.
I’m not going to go into specifics on which measurement frameworks are best for product teams (I’m a fan of teams finding what works for them, I have seen general constructs of North Start + AARRR or another conversion funnel work well for many teams), because the individual metric itself doesn’t matter as much as the mindset you take. The best teams are incredibly clear about what they are trying to achieve. They understand and fix problems with religious zeal.
How will we know if we are successful?
My biggest suggestion: Answer the question “How will we know if we are successful?” This is critical to do for your overall product and for key features. Then WRITE IT DOWN. Product roadmaps, done well, contribute an incredible amount of clarity about the Why, What, and How of achieving your team goals.
“Are we there yet?” should be a daily question. It takes a lot of energy to focus a team on a single goal and help everyone remember what that is. Over-communication is a superpower when it comes to setting and using strategy.
When you are focused on measuring your progress vs activity, you realize that when you aren’t making progress you need to adjust.
This is why humility is the most underrated skill for product managers (and leaders in general). When you are humble, you can admit something didn’t work. In a world where many people believe the lie that the product manager is the CEO, it’s the type-A talent who are used to making things happen that sign up as PMs. Product managers aren’t a group of people to sit and bide their time.
But the exact thing that attracts PMs to the field also fuels the feature factory.
The factory and waste
The majority of new features don’t accomplish their goals. All too often the reaction to underperforming features is to try to build more. The first option considered should be “Do we even need this?”
90% of a product manager’s job is to find pain and reveal the truth. Asking why, observing behavior, and testing solutions are of utmost importance as PMs seek to understand the truth.
We waste time, money, and energy when we let shipping something new overshadow finding and addressing pain.
This is only made worse because what is easy to create is hard to maintain.
My (painful) story about waste
I remember getting handed a mockup for a new section of the app I was managing. It was beautiful and got lots of instant ahs and oohs. The idea seemed cool and executives were drooling over it. The design had been created outside the normal team process by a design leader, but other executives seemed to like it so they didn’t care.
What was easy to design was hard to build. When we broke down features, it was going to take 6+ months to build this new chunk of the app (given the reality of other work the team was already committed to and refactoring that would be needed). The team (myself included) had a ton of questions about if this design would actually accomplish the goals we wanted to achieve. But it became clear executives didn’t want much discussion.
“Don’t ask questions, just build it.”
I’m sad to say that I caved. I didn’t push hard enough on questions like “How can we test this?” or “What aren’t we sure about.” Sales liked it and a few current buyers said they liked it, so the executive team was sky high about it.
How the product was wasteful
We ended up building it in 4 months through painful negotiation (the initial mockup was incredible feature-rich). What is easy to slap on a design (seconds) can be very painful to build.
But a weekend design that took 4 months to build isn’t even the worst part. The worst part was the maintenance.
After the build, not only did adoption not take off like predicted but then we had all sorts of maintenance issues:
- Bugs to squash on these new pages
- More complex data to maintain
- Heavier UI with more options for users
- More for sales to demo
- Internal questions to answer about the new feature
And all of this for a feature that the team had no direct user feedback about. I’m kind of embarrassed about my part in this, but I hear stories like this on a weekly basis in my conversations with product managers.
The main issue
Now, this story could be me griping about how I was pressured to build something, and executives should trust their teams and not force things to be built. While that is a topic worthy of discussion, here’s the main issue: I stopped advocating for users and just built something I knew was unlikely to work.
As a product manager, even when proceeding under executive order, you can still be an advocate for the user, you can still find creative ways to get user feedback, you can still push to release iteratively and gather data and feedback while you do that.
Your job is to obsess about your users. Do not get sucked into only building and forget why you were hired. (tweet this)
How you can stop the waste
How do you know if something is working? Ask yourself: What does success look like? Then think about the smallest way you could test that.
Being able to plan, test, and take action is one of the greatest skills you can develop as a product manager. This is one reason a design sprint is a powerful recipe — it takes you from idea to user-vetted prototype in just 5 days.
One reason this is all so challenging is that most of the cost is invisible. Invisible cost kills companies. Wasted time, money, and energy add up.
When you aren’t moving rocks (or doing other menial work), what impacts productivity is hard to see.
Make the invisible visible.
It’s why the best product managers aren’t just 1.5x or 2x better than counterparts, but up to 100x better. The difference between an incredible PM and a mediocre PM can be seen in the impact to users and the business. Looking at what features shipped the difference isn’t that stark. Look at what happens to your business and to your team, and you’ll see the impact.
Ask yourself more often how to stop vs start.
- “What can we say no to?”
- “What can we stop doing?”
- “Which backlog feature or feedback can I not worry about right now?”
The best product managers can see what others can’t. While this includes seeing problems and inspiring a product vision, we should work harder to see the truth about how much building something actually costs. Don’t build just anything … take time to build the next right thing.