Product Manager Pairing
Mark Henry and Anna Kelk
Our home and search results pages are vital to our candidates finding jobs quickly and easily but they show signs of age and were crying for a rebuild. The resulting “Houston” project was big, ambitious, and needed two product managers. How did it work? Read on…
Anna: I was lucky enough to be assigned to the Houston project directly after starting at SEEK; joining a team of passionate people who wanted to solve big problems and change the way teams collaborated to deliver products. The early weeks and months were hard; the team was not gelling, the more we dug under the hood, the harder the task was becoming and external stakeholders were looking for more tangible evidence of progress. We worked hard on team dynamics, built alignment and trust, but increasing speed to market required more focus and help from different groups within the business. Joining forces with another team was necessary to deliver the best possible experience for candidates.
Mark: As a product manager I’ve always considered myself a lone-ranger type out there on the plains, doing my thing with a team. I could exchange war stories with my product manager buddies, but never worked directly with them. So when I was asked to join Houston I was really keen on the project (game changing, big, complex and hard is my idea of fun). I was not so sure about working with another product manager. What if we disagree about everything? What if she always wants to prioritize her parts of the project? What about sharing the glory? Did you have doubts when I joined your team, Anna?
Anna: Product Managers are territorial by nature. Other PM’s may foray onto your turf for short periods but they quickly return back to home base once they have achieved their objective. Working side by side with another PM for an extended period of time would be a new experience. I had mixed feelings about Houston being absorbed into a team who spent their days wrangling with a much larger, complex codebase. Luckily there wasn’t too much time to mull over the possible pitfalls…
Mark: Yes, there were a few crazy weeks in there. We had to take what was essentially a stand-alone, logged out experience and be able to seamlessly feed a small proportion of our audience to it. This was complicated by the use of a new AWS environment in Sydney when our existing site is hosted in Adelaide. Suddenly I found myself talking about a small pipe from Adelaide to Sydney and managing traffic through it. We had engineering building a new router which basically directs every request for Seek pages to the right place, nothing like the high availability, high reliability required there. Then we had authentication woven into the old stack that we had to replicate outside of it. Plus APIs to enable in the new environment. And SEO. And marketing messages. And analytics. So suddenly we had about 6 streams, all doing work required for launch, and not a drop more. When would you say it all started to come together?
Anna: Understanding that one team could not effect change across 6 different areas was key. Forming a dedicated group of specialists to deliver against each epic gave us the structure and focus we needed. To cross-skill and build momentum, developers who had previously been working on the new stack paired with newer engineers, engineers paired with UX, product paired with engineers. It wasn’t always easy, but it worked and velocity increased. Pairing was crossing over into the product space too; Mark and I had originally split our ownership across the logged out and logged in experiences and this was loosely followed but we’d regularly spend time sharing metrics, debating various approaches and bouncing ideas off each other.
Mark: Yes, I thought it was a big step to have a single high-level board with 6 streams on it and weekly joint stand-ups with someone responsible for each stream there. Our BAs did a great job getting that together and it gave us all overall objectives. From the product point of view, the turning point for me was clarity on our goal from an analytics perspective. If you look at our core purpose as helping candidates to find jobs and complete applications, in rebuilding the home and search, it makes perfect sense to use total applications as an overall checkpoint. Then we prioritized everything based on this metric. Features that contributed significantly made the first release, others were delayed or retired. Having that as a foundation of all prioritization discussion gave us a common ground. From that point we could discuss features we each owned against a baseline. It meant we could have robust discussions with clear boundaries so it was never unfriendly, but really got into the issues as well. In that way it was refreshing to have someone else in the team with a product mindset to back up and add to discussions from my perspective. I also picked up some different approaches. I tend to dive for the data and come back up to discuss possibly with too fixed a mindset. Anna talks more around the problem with team members getting more buy-in and collaboration, an approach I have taken on board. I think I’ve come out of the experience a better product manager.
Anna: Having well defined KPIs is critical for value and prioritisation discussions. And everyone in the team understanding how they are contributing to this goal anchors group decisions and helps to maintain focus. Mark is highly analytical and his skills were very helpful when developing baselines and measurement. Being able to analyse and contrast perspectives in depth with another product manager ultimately led to more robust decision making. To make product pairing work you need to maintain a laser focus on customer outcomes, be open to new thinking and able to challenge ideas constructively. If you can find the right balance not only will you learn and grow as a product manager but the results will exceed expectations and you’ll have fun along the way!
