 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Not long ago, I posted a bit of a rant on Twitter, as I’ve been known to do from time to time:
It seems this has struck a chord — 650,000+ impressions later, I’ve been invited to explore these ideas a bit further.
If, like me, you’re from the Marty Cagan school of product development, you’re familiar with the construct of the triad as the core team responsible for defining and delivering products. Triad is shorthand for three roles, which balance out each other and are each responsible for a different kind of advocacy:
If we, as product managers, are accountable for value, what creates more value than adding a new feature to the product? In many software companies, this is the ultimate measure of success, and incentives are structured disproportionately around delivery of new capabilities (output) over achievement of user and business objectives (outcomes).
I’d argue that product managers who limit their understanding of value to this stripped-down definition are heading for heartache down the road, for themselves and for their business.
It’s intuitive enough to recognize the interdependency between the roles of the triad and their respective concerns. As product managers, we understand that without engineering, we won’t be delivering much of anything. Or that without design, we might end up with “developer art” in our implementation that won’t thrill our users.
With no product manager accountable for business value, will engineering and design know what investments will be most impactful? But our reliance on each other goes much deeper than this.
It’s a common refrain in tech that product managers own the “what” and engineers own the “how.” At a coarse level, this is a good guideline, but if we want our product to succeed over the long term, we’d all better care about the how. (And I’m not talking about decisions around the tech stack, which are better left to the experts in engineering.)
There’s a real danger for product managers to become overly fixated on shipping new capabilities without taking into account the cost of doing so. With few exceptions, every square inch of surface area we add to the product increases its complexity and reduces our ability to move quickly. All that code needs to be reviewed, covered with tests, secured, scaled, patched, maintained, operated and eventually deprecated. Pathways through the codebase become increasingly overwrought as conditional logic is wedged in to (hopefully) make all these features play nicely together.
This goes for design as well. Information architecture is an area that frequently suffers in the rush to crank out new features.
When our products are small, we can deliberately design elegant navigation and workflow. In our rush to add the next cool thing, we often end up short-changing the investment it takes to maintain that coherence for users.
There’s a healthy tension built into the triad model, and I’m not suggesting we throw that out the window. If as a product manager I was overly reactive to the concerns of either engineering or design, I’d be in danger of abdicating my primary accountability for creating value.
However, I do think that product managers have a unique role in the triad, one that requires them to consider the concerns of the other roles because they are, in fact, inseparable from the success of the product itself.
If we are accountable not only for the short-term delivery of new features, but for the ongoing health and quality of the product we build for our users, we need to consider the design and technical debt we continuously create as we build. There will be times we will borrow against our future quality because time to market is critical, and that’s more than OK — time to deliver is an important part of how we evaluate product value. But after a while, that debt will come due and ignoring it is effectively like chaining a cinderblock to our legs and jumping into the sea.
Understanding and managing debt requires high trust between the product manager and their counterparts in the triad. If incurring some debt is OK (or even good), how will we know when it’s gone too far?
First, we need to actually recognize and care about these longer-term dimensions of product health. As product managers, we must view this as part of our accountability for creating value. Second, we need to listen when our partners in engineering and design are advocating for paying down debt. We need to support them and create space, not roll our eyes or react with skepticism about whether these concerns are really important.
Unless we’re already so deep in debt that writing new code feels like swimming in molasses or our teams spend half their time (or more) putting out fires in production, I discourage any team from scheduling “quality sprints” or similar. This would be a timeboxed interval with specific goals around fixing bugs, upgrading dependencies or doing other kinds of refactoring.
I’m also not a fan of using target percentages for different types of work — such as the popular practice of setting aside 20% of a team’s time for maintenance. There will be a natural ebb and flow to our work, and methods like these invite waste or even theater.
What I do recommend is that the triad regularly talk about balancing feature delivery against these other concerns and that whatever system their team is using for tracking work makes priorities across investment areas abundantly clear. (For more on flow and time theft, see the excellent work of Dominica DeGrandis.) When teams become practiced at this, we can observe steady streams of delivery that benefit users while making the codebase better.
A parting thought: If we are lucky and our product has even modest success, the feedback and ideas from our users will never stop coming. This is excellent! Engaged users who want to help us make the product better are an incredible gift. Those same users want our product to be easy to use, powerful, fast and reliable, and they aren’t the ones who need to balance the rush to add shiny new stuff against the looming shadow of tech and design debt.
We are.
