Looking for the holy grail of software product management. The proverbial silver bullet? In this post I'm going to reveal what it is 😉
So what is it? Getting relative estimations right? Writing perfect user stories? Building product increments? Well, ok, I admit... There is no silver bullet. The one thing that gets closest of being one is... (drum whirl 🥁)... Just talk!
Talk about what, you ask. The one that matters at the end of the day: The software. The product we are building. More precisely:
Backlog items
Product goals
Business intelligence
I could have included how we build the product on the list, but let's skip that for now.
Next question. Talk to whom?
Development teams
Customers
Business owners and other stakeholders
...and everyone else. Why is talking so important? Software development is complicated and complex, and the nuances of customer needs and goals too intricate to readily describe in writing. Few people understand the technical in's and out's and the customers' businesses. Add to that user needs and UI design.
We need to collaborate to get things right, and collaboration means talking. And listen.
Backlog Items
The pieces we add to the product are usually represented by items in a backlog. The code behind every item is, by itself (ideally) or together with other items, what creates the functionality.
Product ownership means taking responsibility for what to prioritize, and finding the best possible balance between desirability, feasibility and viability. This requires understanding of users' needs, what's technically possible, and what customers' need and what value they see in your product.
New pieces need to work with what's already there. What looks like a trivial feature can turn into an implementation nightmare because of limitations and technical choices made years back.
Ideally items are independent of each other and developers spend a lot of effort trying to minimize dependencies and maintain maintainability, but there will always be constraints, and they tend to stack up the more we add and as time goes by.
As product owner you need to have an ongoing conversation with teams about the backlog items for at least three reasons:
You want to know if what you ask for is surprisingly costly or easy to do. Often teams can offer insights and cheaper alternatives.
Seemingly straight-forward features will also be misunderstood. Listening in to team meetings and making yourself available to answer business questions helps avoid misunderstandings and unnecessary work.
Conversations about backlog items give important clues about the state of the product.
Product Goals
No matter how long and detailed specifications you write, they will be misunderstood and open for interpretation. The innate complexity of building software means it's not a straight path from writing down a list of requirements and then wait for the product to be built.
In complex systems trying to central control is futile. Relationships between actions and effects blur.
As product owner you need to communicate goals, values and priorities:
It empowers teams and makes it possible for people to self-organize and solve problems quickly and effectively.
It enables good day-to-day business decisions as people understand priorities and what is important – and why.
Customer and internal stakeholders understand what the product does and how they can benefit from it.
Business Intelligence
In bigger companies (read: anything but startups) development teams often become more and more isolated from customers and users. Internal business owners and stakeholders are often also hard to reach. If in luck, you are invited to a town hall meeting (also fondly called "all hands" and "all company" meetings) where the latest quarterly reports and customer sales are shared, and goals and company wide news presented.
Many teams long for customer feedback and to understand stakeholder priorities.
As product owner it's your job to help fill this void:
Openly share things you pick up from customers. Good and bad. People love hearing about how what they built are loved by users. They also want to improve the product and understand what does not work well.
Forward information from business owners and stakeholders to give teams context and help them make good decisions also when you are not around (which, of course, shouldn't be often).
Final Thoughts
Just talk. It might not be as simple as that though. For it to work you need psychological safety. If that does not exist, I'm not so sure talking always make things better.
Also, you get what you ask for. If you didn't get what you expected or wanted, it's probably because what you asked for could be misinterpreted, and you didn't care to have an open continuous conversation with the ones delivering. As the saying goes, assumption is the mother of all f**kups.
Do you have other examples of why talking is important. Or do you disagree? Either way, I'd love to hear back from you.
Comments