These cookies make our website usable and secure. They ensure fast loading, basic functions, and general reliability. Without them, the site simply wouldn’t work.
Product
Feb 26, 2018
I had just returned to Sydney in 2014 from a 2 year stint at a startup in New York when I received the email, job offer attached. Four weeks later I showed up for my first day at work in Madrid, meeting our 5-person engineering team, QA lead and the CTO/Co-founder.
Product planning and prioritisation were a little haphazard at that stage, so it was relatively easy for me to make an impact by adding some lightweight process. Since all the engineers fit around a table, communication wasn’t an issue, but process and prioritisation were important to get right.
Before too long, with this process and prioritisation framework in place and the company beginning to expand, it was time to hire more engineers to support that growth. Alongside our Head of Engineering and CTO we had to quickly figure out what skillsets were needed next to scale up, and how to find those people (on a budget).
I’m a product guy, I like to think my background means I have a pretty good balance of skills, a general product sense and therefore an understanding of what to build next and how difficult it’s going to be. The company’s rapid geographic expansion meant that prioritisation with limited engineering resources was difficult, but over time we grew our team by 15x so that problem was slowly replaced by a new, less familiar challenge. I’d been the first, or early hire in a few startups by now and led teams of engineers to launch and scale products, but it became apparent that our web and mobile apps, our backend, our matching algorithms, they were no longer my products. Without planning it, I was now no longer a product manager and I wasn’t building products anymore. I was building teams.*
It’s not the topic of this post, but as many others before us, we realised that small, independent, cross-functional teams ship faster. We had passed through the awkward stages of having silo’ed teams separated by technology and had hired enough personnel to form cross-functional teams dedicated to a part of the user journey, a business goal or a small product. Once you arrive in this position, where teams can now move in many different directions, there are 3 things that happen:
You can no longer keep up with the volume of daily decisions that need to be made
Spending too much of your time on one part of the product(s) means you neglect the others
In order to really get the most out of your team you have to give them ownership over what they’re working on
Clearly, it wasn’t possible at this stage to keep product direction going for 10 different development teams. Forming these teams the right way, ensuring the right members, the right communication flows and processes, this was really what was needed now and the only way I was going to 10x myself.
It’s not for everyone. As you take on a product leadership role you grow further away from the actual delivery of products. You’ll still be key in setting and communicating a vision, but how that vision is translated into real world products is now driven by the people in your teams more than it’s controlled by you. This is not an easy transition, so the following are a few snippets of wisdom and learnings I’ve picked up along the way:
Instead of thinking about how different parts of systems communicate with each other as a Product Manager, your teams become like different parts of a system and the processes and communication flows you set up become your API’s.
Of course you need to figure out what skillsets you need, but it’s much more challenging than that. You’re dealing with humans who bring their own personalities, experiences, strengths and weaknesses. They may not necessarily view the world with the same lens that you do, or their teammates for that matter. You need to carefully consider how you construct these teams, how they will interact with each other, and how that will change over time.
You need to redefine how you gauge your own success. To me, being a great product leader is a bit like being a great builder. If you’ve got the right team foundations in place, lay the processes and communication flows so that the teams can operate without you needing to micromanage, you’ve done a good job. A good builder is one you don’t really need to think about or call upon once you’re actually living in the house.
Getting out of the way after being hands on is tough, but you need to realise you’re only stepping away from the front line. You need to be active to ensure that your teams are set up to create great products. This is constantly changing as the team changes, so you need to adapt team structures and processes to ensure to keep teams small, communication lines minimal and ensure good product decisions are made, without you actually making them. You find yourself thinking more about what makes good product management, rather than what makes a good product.
Don’t step too far back. You need to stay enough to the detail so that you can get involved when an important product decision needs to be made or corrected. Delegating decision making is great, but with many parts operating in their own best interest, it won’t always lead to the best outcome for the company. Sometimes you’ll need to make collective decisions and steer the ship.
All of these are areas I’m still working on and learning along the way. I like to think I’m acting as a servant leader rather than a manager, and that I’m looking to ways to lift people in my team up so they can be successful, but I’m still figuring out how to get better at guiding people to success without telling them what to do.
The transition from Product Manager to Product Leader has been an unplanned, but natural progression, helped by the fact that there a lot of similarities between the two roles. Prioritisation, trade-offs, communication are all vital in both roles, a great Product Manager needs deep understanding of their users, and a great Product Leader needs a deep understanding of their people.
Engineering
May 22, 2025
Culture
Jul 20, 2023
Culture
Nov 11, 2022
Culture
Nov 09, 2022
Engineering
Jun 01, 2022
Product
May 06, 2022
Engineering
Apr 05, 2022
Product
Mar 22, 2022
Cookies are small text files stored in your browser. They help us provide a better experience for you.
For example, they help us understand how you navigate our site and interact with it. But disabling essential cookies might affect how it works.
In each section below, we explain what each type of cookie does so you can decide what stays and what goes. Click through to learn more and adjust your preferences.
When you click “Save preferences”, your cookie selection will be stored. If you don’t choose anything, clicking this button will count as rejecting all cookies except the essential ones. Click here for more info.