Introducing Productboard Pulse. Exec-level insights into what your customers need, powered by AI.
A special thanks to Dean Peters for collaborating with us on this project!
Watch out! The world of product is full of Dangerous Animals—stakeholders and situations that, if left untamed, can get in the way of your product plans. Our original list features the WoLF (Works on Latest Fire), RHiNO (Really High-value New Opportunity), HiPPO (Highest-Paid Person’s Opinion), ZEbRA (Zero Evidence, But Really Arrogant), and the Seagull Manager.
Now we’ve got even more animals to add to the menagerie. Meet the Dangerous Animals of Product Management 2.0!
In this post, we’ll look at some tactics you can use to manage the new Dangerous Animals and prevent them from running wild in your organization.
Left to their own devices, PUFFIns won’t have any trouble keeping themselves busy. But they’re simply checking items off a to-do list rather than making an impact on the business. Try a few of these tactics to help them align their work to actual business outcomes.
Feature Factories tend to occur when runways are at risk. For example, when funding is running out, sales aren’t being made, or something like COVID catches everyone by surprise.
While you can’t prevent these things from happening, you can try to avoid being reactive when they do. When you find teams chasing every dollar or task as a quick-fix solution, remind them why you’re focusing on higher impact activities instead.
One of the best ways to keep everyone aligned on your product vision and strategy is by having a key artifact like a strategic roadmap that focuses on outcomes rather than outputs. Make sure everyone has access so they never veer too far from your North Star.
With a tool like Productboard, you can invite stakeholders from across the organization to view or contribute to your roadmaps. You can tailor specific roadmaps to their needs, and they won’t see any roadmaps that are private or that have only been shared with specific colleagues.
Make sure your work is led by a validation process. This can be the “tiny acts of discovery”, seeking input from your customer advisory board, or anything else that helps keep your users and desired outcomes top of mind.
Engineering math is highly optimistic. This often occurs because engineers think in terms of code being written, but just because the code is done, that doesn’t mean the delivery of value is done. As a product person, you need enough technical understanding so you’re aware of the constraints and impact of different decisions.
Try these tactics for generating more accurate estimations.
Keep in mind that there are different factors to consider like quality assurance, go-to-market, and onboarding for your Customer Success team—and don’t forget to account for all these factors and steps in your timelines. It can help to keep a history of past estimations—both good and bad—and review these so they can inform your future estimates.
Make sure that your user stories are as tiny as possible. You’re looking for one outcome for your user based on a set of given conditions, one “when” and one “then” (as in “Given this set of conditions, when the user does X, Y happens”). Any more than this and you could be aiming too high, which could slow down progress and impact your timeline.
PUMAs like to make snap decisions and move fast. They’ll often hear a single anecdote, data point, or tactic and immediately want to act on it without taking the time to validate their assumption. But it doesn’t matter how fast you’re going if you’re moving in the wrong direction.
Customers often speak in solutions because they don’t know any other language. But it’s our job as product people to translate their solution space language into problem space language. Make sure to ask lots of questions so you fully understand their context and motivation. An exercise like the “five whys” can really help here.
Try to elevate assumptions into hypotheses so you can test them and measure the results. Remember, this doesn’t need to be a full-blown mockup or anything that’s labor intensive to create. Your goal is to run small experiments on an ongoing basis so you can collect results and add data to the conversation.
Cognitive biases came about to help us avoid getting eaten in the wild. If we see a tiger about to charge or a fire that’s going to burn our hand, we move quickly out of a self-preservation instinct. But in the business world, we’re rarely dealing with actual fires, so we can (and should) take the time to be more thoughtful about our decisions.
There are hundreds of cognitive biases and you definitely don’t need to catalog all of them, but it can be helpful to familiarize yourself with some of the common ones that are likely to impact your work.
For example, confirmation bias occurs when we only highlight or remember information that confirms our pre-existing beliefs — and ignore or forget anything that disproves them. The escalation of commitment – or sunk cost bias – occurs when we feel like we’ve already invested a lot of time or resources into something and don’t want to give up, even if all signs are showing that it’s not working.
The more time pressure we are under, the more susceptible we are to cognitive bias since it’s a form of mental shortcut. To limit this, try to break large tasks into smaller ones so you can buy yourself some time to experiment. Look for ways to take a “now, next, later” approach so you don’t have to make all your decisions at once.
Whenever you can, don’t make decisions on your own. Seek input from other sources, whether it’s your broader organization, feedback from your customers, past conversations, or anything else that helps you broaden your perspective.
YAKs are quick to jump on any kind of number or metric. But just because something has a number attached to it, doesn’t necessarily mean you should pursue it. Here are a few tips to help ensure your KPIs are actually beneficial to your users—and your business.
Remember that metrics can have both intended and unintended consequences. Assessing engineers on lines of code written doesn’t make your software better; it just incentivizes writing more code. Whenever you’re tempted to set a new metric, make sure you can tie it to desired outcomes for your users and your product.
You can run into trouble when your organization uses metrics to judge or punish people. There should be psychological safety around metrics so people aren’t afraid to share “bad news.”
Don’t forget the “I” in “KPI” stands for “indicator,” which means it’s important to treat your KPIs as opportunities to course correct rather than immutable final results.
Create a practice of returning to your KPIs often to ensure that the context hasn’t changed. Add in color with qualitative input whenever possible. Taking this approach can help everyone remember that your work is never just about numbers — it’s about the people.
