Get product resources, conference updates, along with access to an exclusive Slack channel by subscribing below.
To build the right thing, you need to build the thing right.
Liz Keogh explains the importance of good engineering practices in the quest of producing really good products. If you want to build the right thing, you need to be able to change direction based on what you learn as you build. Good engineering practices put you in a position to safely change direction midstream.
To build the right thing, you need to understand the behaviors you seek to change.
Your team can use impact mapping to explore what behaviors you should try to influence in order to reach a particular objective. You can use impact maps to discuss assumptions, align with organizational objectives, and develop a greater focus on your products by delivering only the things that lead directly to achieving organizational objectives.
To build the right thing, you need to avoid the build trap.
The build trap is where an organization continues to add features to their product without stopping to find out if they are satisfying their customers’ needs. Melissa Perri discusses how to avoid the build trap by placing an emphasis on satisfying your customers’ needs rather than just churning out a bunch of features.
To build the right thing, you need to look beyond outcomes.
Building the right thing is usually taken to mean that you are delivering a particular outcome. Yet as John Cutler points out, just saying “deliver outcomes” is not sufficient. Those outcomes need to map back to the longer term organizational outcomes.
Des Traynor from Intercom discusses in this podcast that in order to build the right thing and scale your company, you need everyone on the same page. Shared principles, value, and mission provide that page and give guidance to your team when it comes time to make decisions about what the right thing is and isn’t.
For most product people, an inordinate amount of time is spent battling stakeholders with data in order to keep new features from being added to a roadmap. So the prospect of removing features already implemented is clearly a tough one. But there are some compelling reasons for you to take out your knife.
People are not really into using products. Any time spent by a user operating an interface, twisting knobs, pulling levers or tapping buttons is time wasted. Rather, people are more interested in the end result and in obtaining that result in the quickest, least intrusive and most efficient manner possible.
In a fast-moving product development environment, it’s the product manager’s job to juggle priorities. Inevitably, as a certain product or feature improves, others will be left behind. Paul J believes that there are two types of debt — an accumulation of unnecessary features and the discrepancy between different products in your ecosystem. So occasionally, we must reflect on where our product debt stands and take time time to pay it down.
Some techniques, as outlined by the Hardcore Product Management blog, are a little less technical (and inherently more risky). In Agile Development, requests are organized by Must Haves, Nice to Haves etc. To decide which is which requires plenty of gut instinct. But it can be applied to product management prioritizing too, preferably backed up with data. Similarly, you can Stack Rank requests whereby the apparent least important ones are pushed to the bottom and ignored.