Product Leader Interview Series: Grant Hodgkinson

Taking a Product Team from 0 to 1

For episode 3 of our ‘Product Leaders interview series’, Albany Growth’s senior consultant Max Flint  sat down with Grant Hodgkinson (previously CPTO at Tabeo, CPO at Peak).

As a Product Leader with a background in high-growth companies, it was useful to get his insight on how Product teams are scaled, utilised and amplified through varying stages of growth. 

Here’s what Grant told Max:


Introduction:

I originally studied business and accounting in Johannesburg, where I was born. It was during that time that I discovered I really enjoyed using technology to solve business problems. That quickly grew into a technology services business. After selling that, and building another Internet-focused services business, I became more interested in the scale of product companies.

My first role in a product business was the establishment of the sales channel for Mimecast EMEA – a real challenge as we were driving the shift towards cloud and subscription. I moved to London into 2012 to build the product function for Mimecast, leading up to their IPO. That was very interesting as I was involved at the grass roots in building the product for the US market.

After just under a decade at Mimecast, I was interested to get back into the craziness of startups. I’ve seen that founder CEO’s are often thinly stretched building a business, working with investors and selling to customers. I have enjoyed being that capable partner to build a product delivery machine, lead customer-centricity, and helping the growth team articulate the “why” about what we’re building.


Foundational Steps:

Q) When building a product team from scratch, what are the foundational steps you prioritise to set the team up for success right from the start?

Building a strong relationship with the product muse is critical. This is often the founder. Finding a way to tap into their passion for the problem to be solved, and why, is critical for success.

Secondly, it’s normal that the engineering team will be established already. Coming to their table and understanding their realities is important. Creating a single identity as a delivery machine as the 2 teams come together really helps, too.

And finally, I encourage teams to actively avoid complexity. It’s easy to make problems look bigger than they are. Distil issues to their core “truths” and wrestle them together.

 
Team Dynamics:

Q) How do you go about fostering collaboration and a positive team culture within a newly formed product team?

It sounds cliched but I believe in the value of time spent together (physically) as a team. Even when a team is primarily remote, putting in the time to be in the same location for a period is transformational.

As most companies embrace hybrid work models, I’ve found that holding a regular team conversation about how we collaborate – beyond the normal “ceremonies” – is very useful. It often takes a few cycles to get the conversation going, but the team becomes comfortable working through suggestions, and this helps build positivity.

Finally, giving the team to opportunity to look back helps. Retrospectives on projects – good and bad – can yield amazing insights and improve collaboration.

 

Defining Vision and Goals:

Q) How do you ensure that the team not only understands the vision but is also aligned with it?

Firstly, I think it helps to have the vision reduced to writing. I prefer prose, as if I was telling a story. Sometimes that is best augmented with something designed as well. That creates a foundation for the vision to take hold.

Secondly, I spend time sharing the vision and discussing it. I often distil the vision into a few sentences and remind the team of it at regular meetings. I’ve realised that saying something 7 times is often not enough to get it embedded.

The final point is about checking for alignment. I find it useful to ask team members to articulate the vision as they have internalised it. It’s also useful for the team to review the outputs of work, and compare that to the vision, adjusting or staying the course, as needed.


Talent Acquisition:


Q) Finding the right people for the initial team is pivotal. What attributes do you seek in individuals you bring on board when the team is still in its infancy?

The top attributes I find most attractive in new people:

  • Those who try to find ways to simplify complexity
  • Who have a true passion for the domain and solving customer pains
  • Who have a desire to work in a team
  • Who have the ability to work across multiple threads of work

     

Balancing Agility and Structure:


Q) How do you strike a balance between providing enough structure for a nascent team and allowing flexibility for innovation?

This balance is never easy to strike. But also, it shifts as the team grows and the company matures.  I like to think about structure as the way to remove friction just sufficiently to help the team work better. To preserve the balance, I tend to focus on 2 things:

Firstly, I find it important to ensure that key stakeholders are bought into the friction identified, and that it’s worth addressing. Once again, product work is a team sport.

Secondly, being open to introducing a change means being open to letting it fail as well. I ensure the team is well prepped to give feedback from their perspective so that we can openly evaluate the results and continue to make improvements where necessary.

The concept of balancing structure and flexibility is not a once-off thing, either. Reviewing it openly and honestly from time to time, even if to agree on no changes, is equally important.


Handling Challenges:

Q) Could you share an example of a significant challenge your team faced early on and how you navigated through it?

I was involved in a business where product was led by engineering, and it had decided to focus on resolving technical debt, to the exclusion of addressing burning customer pains on the platform. As I delved further, it became clear that customers would ultimately face a degradation of features which would aggravate churn which was already bad.

I started a series of conversations about churn, and its impact, and how we (as the delivery machine) could help. This helped to introduce a shift in approach to recognise technical debt but focus more on customers and how they could be delighted in using the product.

Ultimately, debt took longer to address, but burning issues could be addressed, and customers retained.

 
Advice for Aspiring Leaders:

Q) For those aspiring to lead product teams, what advice would you offer based on your experiences in taking a product team from 0 to 1?

Taking a product team from 0 to 1 is a journey, an evolution and not a revolution. Apply first principle thinking to the problems you face as they are unique – don’t just apply a framework or a solution you’ve seen before in a different context as it’s likely to fail.

Secondly, build solid relationships with customers and (ideally) prospects. In early stages, qualitative feedback from great conversations with customers is gold. Equally important are relationships with internal stakeholders. In particular, leaning into growth teams to understand how to work better together will be mutually beneficial.

Share this article

Search

Categories

Recent Posts

Give us a call

Follow Us