To survive as a product manager, you need to put strategy first and be able to balance this alongside being heavily involved in delivery. All ideas need testing, and you need to truly listen to your customers to deeply understand their problems, said Emma Sephton. She shared her lessons learned from becoming a product manager at the Agile Greece Summit 2019.
When Sephton transitioned to being a product manager, previously having worked as a project manager, she started to do research into best practices for product management. She gained expectations about the role and learned that she should be focusing on strategy and problems, rather than the delivery side and output:
One of the first tips I remember learning about is the "five whys", which really show how as product managers we should be focused more on the why and digging deep into the problem. Leaders in the product management field, like Marty Cagan, remind us that we should focus on outcomes to work as empowered product teams, which means we need to have a strategy based around outcomes and objectives, not features.
Sephton mentioned that she sees many talks and blog posts reminding us that product is about outcomes over outputs, problems not solutions. "It’s a common problem amongst organisations that we are often dragged into the how, which leaves us less time to focus on the why," she said.
To balance between strategy and delivery, Sephton introduced the tool ProdPad. She mentioned that it helped her ensure she was focusing on strategy and had the right answers for why they were building stuff. "Having a structure to bring ideas back to problems and keeping the roadmap focused on outcomes helped me make sure I had the answer to those questions," Sephton said.
She also used time management tools to help make sure she was spending her time wisely:
When you’re so heavily involved with development teams, making sure they have enough work and projects are progressing well, those things are very time-consuming and mean you don’t have much time for thinking about strategy.
Sephton mentioned that she tried to timebox work and used the Eisenhower matrix to make sure she was aware of the urgency vs importance of work tasks, rather than just fire fighting and working in a reactive way, which can be a time-suck.
"I learned that all ideas, no matter how good you think they are, need testing," said Sephton. She suggested to always listen to customers; don’t think you know better than them, truly listen to what they are telling you. They may talk more about solutions as that’s how they understand the world, but you need to listen deeper to the problems they are sharing with you, she argued.
InfoQ interviewed Emma Sephton, account manager at ProdPad & co-organiser ProductTank Oxford, after her talk at the Agile Greece Summit 2019.
InfoQ: What made you change from being a project manager to becoming a product manager?
Emma Sephton: It was more of a natural shift. I was a project manager at the University of Warwick where I managed various education programmes, mainly related to teacher training. There I learnt more about technology-enhanced learning, and subsequently moved to a learning technology company as a project manager. Over time though, I was more involved in the product side of things, so it made less and less sense being called a project manager. And so I gained the title product manager, not fully aware of what that meant. I did a lot of research and found resources like the Mind the Product community and tools like ProdPad (where I am lucky now to work!) that could help me become a better product manager, having been so project-focused previously.
InfoQ: You spoke about your expectations regarding the product management role when you switched to it. What expectations turned out to be true? What didn’t?
Sephton: Working in a small company, it was difficult to find a balance between focusing on strategy while also being accountable for delivery, hence my talk for Agile Summit being about this! Now being an account manager at ProdPad and speaking with lots of customers, I see we’re all in similar positions.
Companies are in varying states of change, learning how if they focus more on outcomes, and particularly allow product managers to strategise and consider problems and work on outcomes (rather than how many features they can launch every month or quarter), then they see greater benefits and a better, well-purposed product. One great exercise is Teresa Torres’ Opportunity Solution Tree. It’s a great tool to remind us that there are a lot of potential solutions to problems, and encourages us to focus on the desired outcomes and explore all possible opportunities, as opposed to thinking of a great idea and getting stuck on it.
InfoQ: What are the main things that you have learned becoming a product manager?
Sephton: I now understand the importance of targeting your audience and getting your product to be really good at one thing, to avoid becoming a Frankenstein by trying to meet multiple needs. Get specific and excel at that. I learnt it’s ok to fail and test things as that’s all learning; knowledge and understanding is the only way to a great product.
I found that all the communication skills I’d learned as a project manager are put to the test in product; when you work with passionate people it can be hard to not take things personally, as building products is creative and takes a part of yourself.
I also discovered that the product community is awesome! We’re all so supportive and love to share and learn, it’s great to be part of an industry like that where you can grow together. That’s why I helped co-found ProductTank Oxford (part of the Mind the Product ProductTank community).
InfoQ: How can we become proactive rather than reactive in delivery?
Sephton: In order to become proactive, you need to have understanding and information. Continuous discovery through something like dual track agile provides a good example of how you can achieve this. In this approach, teams have both discovery and delivery work happening concurrently, as opposed to waterfall, where first discovery would happen, then the delivery work. This process allows you to iterate quickly and learn from testing and gathering feedback, which then helps to better inform further development work. Whereas in waterfall, you have to make a lot of assumptions up front and then people would only get their hands on it once it’s done, which is often too late to make effective changes, resulting in costly mistakes based on said assumptions that have not been tested effectively.
Teams become reactive when they aren’t informed or know what’s coming up; they just get told to build x because someone, either an internal stakeholder or customer, has told them to. They don’t have the understanding as to why they are building it, so the teams then can’t inform how to make that the best solution to the problem they’re looking to solve. Through empowering your product and delivery teams to constantly nurture their product backlog of ideas, allowing them space to listen and understand customer needs, your delivery will become better focused on improving outcomes that meet both your business and customer needs. Having an outcome-based roadmap, rather than focusing on timelines only when it comes to strategy, will help with this.
