Doubling up Product Management
Being a Product Manager is fun, but it’s also very hard work with all the different tasks there is to juggle. You should be on top of everything that goes on with the market and your competitors, collect user insights, work on your strategy, test your products and be all over the data, do product discovery, craft job or user stories, review designs, manage stakeholders, be there for the team, motivate and inspire the team, follow up on progress, work out the launch plan AND have time left for big and small creative thoughts. To be successful, there are a number of traits your are supposed to possess. You should understand tech, business, UX, the domain you’re in, be creative and visionary, structured, detail-oriented, an excel nerd and you name it. John Vars described this really well in The Bipolar Nature of Product Management. Some people pull it off, but most people don’t. Maybe the Product Manager doesn’t always have to be one person?
In this post I’ll tell you about an experiment that came out of my team at Mynewsdesk, as a part of evolving our agile organisation. The developers at Mynewsdesk practice pair programming on a daily basis. It’s a way of spreading knowledge, get better quality with more eyes on the code and speeding up the problem-solving part of programming. So when we discussed how to best organise our product management team and how to split responsibilities, the idea of Pair Product Management came up. We decided to try, and we put two Product Managers on the new product we were building. What we hoped to accomplish was four main things:
- More time to handle all the different tasks
- Easier to switch between discovery and development during the project
- Speed up problem solving and creative process
- Combine complementary skills and traits of two people
As their manager I could immediately see how the last item fell into place in an excellent way. One very visionary product manager with a really strong sense for visualising what the product could become and great attention to design details (Alex) was now combined with Hanna who is really strong on data, user insights and creating a really valuable product for the users, and a strong drive for getting the product out the door. On their own, each one of them would have done an excellent job, but I would have had to manage them to cover their weak spots. Together, they challenge and help each other to both grow as product managers.
But that’s my view. Let’s talk to Alex and Hanna. I left off to start my own consulting company six weeks ago but went back to ask them a few questions about their experience with Pair Product Management.
What was your first thoughts when the idea came up?
Hanna: I was looking forward to take on full responsibility for our new product together with someone who was as engaged and committed to make it a success as I was.
Alex: It would be a great opportunity to see how pair-product owning could help product development as much as pair-programming helps developers solve harder problems. No matter your experience, it’s always extremely challenging to balance learning, measuring, and building a product. When you’re fast, you lose quality. When you increase quality, you lose speed. The optimal is finding balance. Pair-product owning offered this opportunity.
What are the main benefits of working as a pair?
Hanna: We complement each other and it is so valuable to have someone who cares as much as yourself to discuss best solutions with. It feels like we come up with so much better things together than we would have done if we were alone.
Alex: The benefits are common sense. One product owner is responsible for influencing speed. The other product owner is responsible for scope. The balance achieved through collaboration allows the team to implement value iteratively, starting from a utility product (getting the job done) and ending with user delight (retaining and referring more users) as the full scope is achieved. When the optimal balance is achieved, cost is reduced and the real problem is reached faster instead of quickly implementing solutions that continuously fail to achieve growth.
What are the challenges?
Hanna: When we don’t agree it can get heated since both of us have strong wills and beliefs. There’s not one of us who has the mandate to override the other, so we need to agree on a decision together.
Alex: Pair product management actually helps relieve some pains or challenges. Embracing the chaos between implementing feedback from learning, measuring, and building iteratively will always be difficult. These things operate at different speeds, so it’s never smooth for your team to figure out what fidelity something should happen now, next month, or in six months. The dual-track solution accomplished with pair-product owning helps reduce this pain.
Another challenge is losing knowledge from moving too fast. Moving fast means documentation can be limited. If you’re a small team, knowledge sharing is vocal — but over time this knowledge is lost. Pair product management helps in being diligent with for example acceptance criteria and other forms of knowledge sharing.
Do you have any advice for people who wants to try?
Hanna: Choose to work with someone who is not too much like yourself, someone who sees things from a different perspective. Someone you can argue with, without getting angry or sad. Then, see and focus on each other’s strengths.
Alex: There is never a wrong way in product development. There is only a less right way. This way of doing things can be “more right” for a lot of teams. I recommend it.
It seems like Pair Product Management is a success and that all four goals have been accomplished. But the main benefit is that the end result becomes better faster. Waste is reduced because ideas get challenged early in the process by the peer. Want to know more? Send me an email on maja at majacing dot com!
Originally published at poptype.co.
