How I coach PMs to get great jobs and succeed in Product

Product Management
Written By Norm

Will Chan

From Marketing & Sales

To Group PM & Product Coach

At The Product Coach

In United Kingdom

Background

I’ve been working in Product for over 7 years now working across a wide variety of industries from betting companies to rostering and staffing software. Before I founded my Product coaching business, I was a group product manager and set up an associate PM program where I mentored two associate PMs into full-fledged PMs. I also extended this mentoring program to PMs globally, specifically in the UK and the US.

How did you execute your transition to Product Management?

I never knew about Product Management before I had the opportunity to talk to the Head of Product at Ladbrokes while interviewing for a QA job, but I think the combination of business skills and technical acumen was the perfect fit for me, coming from doing a business degree but also being super into technology everything just slotted into place perfectly in the product management role.

Having said that, it was a steep learning curve; I didn’t know what good was, I had no experience, and the company I joined was a scale-up that was moving really quickly and super chaotic. I guess you could say it was a trial by fire, but I got some great experience and in the long run, it’s taught me some valuable lessons (more on that later).

My marketing background was surprisingly helpful, as I think consumer behaviour is one of the most important aspects of product management. We always talk about being ‘customer-centric’ but having formal education in marketing has given me the foundations on how to think about the interactions between customers and businesses, as well as what drives people to buy or not buy products.

Similarly, my experience working in sales also helped significantly. The best skill you can have as a PM is ‘communication’, generally people aren’t specific when they talk about communication but here what I’m talking about is the ability to communicate with someone to understand what they’re trying to do, what their motivations are, and where they’re coming from; to then bring that internally and change the perspective to talk to engineers about how we can support those customers from our side using our products.

But of course, there were some gaps in my skills and experience. Understanding product development is the biggest one. Filling that gap didn’t require any particular personal project or extra effort outside of my role, simply working really closely with engineers, and trying to soak up as much information and knowledge from them as possible helped me to understand what they’re doing, the constraints, and the specifics in terms of release processes and deployment. I also think that doing QA for 2 months also really helped me to understand the technical side of things, as well as how to test the product to make sure that everything is working as intended.

As I’ve moved up the career ladder, new skills have become important to develop and master. I think as you move up you have to focus more on senior leadership stakeholder management, I was constantly having to interact with CEOs and Founders, which adds a different dimension to the conversations, when you’re literally talking to the owner of the business and sometimes having to tell them that something is going to be delayed or isn’t possible to do at all, you have to know how to communicate those things effectively without putting anyone offside. The other thing that you learn is how to lead other product managers, how to guide and coach them into being successful in their roles, and how you can leverage your experience and knowledge to shortcut their learning and growth.

What's the story behind your coaching business?

Over 2 years ago, I found that I wasn’t ‘in the community’ as much as I wanted to be. I’m naturally fairly introverted and set myself the goal of building my network and becoming the most well-known PM in Brisbane, Australia. I forced myself to go to as many Product and dev events as I possibly could and quickly found myself hosting many of these events including running fortnightly product breakfast, and 2 Product Tank events. I also attended recruiter lunches and breakfasts that they hold and generally just committed to trying to make one friend at each event. Eventually, I got reached out to by the Product Led Alliance and was a speaker at an event here in London for them on their main stage.

Throughout all of these networking conversations in the industry, I found myself speaking to a lot of PMs that fit neatly into 2 buckets.

The first were people who would have maybe two years of experience in Product Management and were feeling out of their depth and without proper mentorship because they were often the sole PM in a company whose founder had no Product experience. They wanted to learn more, upskill, and solve the unique problems they were facing, but they didn’t have anyone to learn from.

The second was people looking to transition to Product Management and trying to get a handle on how they could look at their existing experiences through the lens of Product Management and of course, upskill in weaker areas that they’d need to get a full-time PM role.

Recognising this problem, I started my coaching company. I paid $90 a year for my URL, theproductcoach.io and set up a sole trader company and I started talking to people. I even went as far as emailing the Silicon Valley Product Group to be put in touch with other great Product coaches here in Australia to help develop my skills (and funnily enough, I now get recommended by them for businesses looking for Product coaches in Australia!)

I got lots of great responses from early career PMs looking for coaching but found that it was harder to set up a long-term coaching relationship with them as it can be expensive, so I pivoted to focusing my efforts on helping early-stage startups who were looking to make their first Product hires but either couldn’t afford or couldn’t yet attract a really experience senior PM. I would help them hire their first PM, set up strong Product systems and processes and help train that PM to take over when I exit. I saw it as turbocharging the function in the business and avoiding the very long process of trudging through the mess and learning as you go with limited experience.

I have since moved to London and am continuing to offer these services over here.

How have you helped early career PMs upskill and cement themselves in the role?

As a group PM, I was tasked with hiring a PM to help me, but I didn’t particularly like the resumes that I was getting. I tend to think the product management function in Australia is a bit behind the rest of the world, and the applicants were more BAs or they had been in environments that were very strict with the whole ‘user stories’, ‘epics’, and ‘feature roadmaps’; which is pretty far removed from how we were working at the time. 

I was running a fairly unique product development process utilising ShapeUp (more on that later) and so I foresaw issues with hiring someone more experienced who would have to relearn a bunch of processes. The company was also fairly strict on the available budget for the role. 

So I wanted to find someone who was really early on in their Product journey that would be both fully malleable, as well as willing to put in the effort to learn our ways of working. I spun up an APM program, which gave our hire the full remit of a normal PM with a huge safety net to learn and understand the function without consequence. We hired someone who’d never done Product Management in a corporate environment before and it was a great experience!

Tell us about your style of Product Management, Shape Up

We were running a product development methodology called Shape Up, which was developed by a pretty divisive company called BaseCamp. We didn't have user stories, no epics, no roadmap, no backlog. Instead, you have a ‘shape’ document which is essentially a one-pager that describes a customer problem and suggests some potential solutions to them - this document is developed between the PM, designer and lead engineer. You might have, say 5 Shape documents, and you meet every six weeks to decide how much time to allocate over the next 6 week sprint to each of these problems. All of the key Product stakeholders are involved in this prioritisation discussion; CEO, CTO, Head of Sales, Head of Customer Support, Engineering Manager, and Head of Partnerships.

The prioritisation discussion, called the ‘betting table’, will decide which of the various solutions you decide to run with for each of the chosen problems

During the betting table, we discuss the merits and priority of each of the shape documents presented. The outcome of the meeting is an allocation of time in the sprint to the shapes, it’s possible that some shapes don’t get ‘bet’ on at all, and it’s possible (although much less common) to have a new shape introduced in the meeting. Originally the meetings used to have 20 shapes and take 2-3 hours, but I streamlined the process to be a maximum of 5 shapes and we got the discussion down to about 15 minutes - a huge win.

For example, we might have a big customer who wants one query done on the database for this report, so we’ll do a cheap and nasty one-week fix. Once that’s off the table, we might have a problem with a core functionality for our Product which is scaled and needs to work for everyone so we’ll invest 3 people’s time over the whole six weeks to make it really shiny and sellable long term.

The scope is variable but it’s time-bound. You’re still working through your backlog of problems that need solving, but there’s more emphasis on the scope of your solution fitting how much time you can justify prioritising to fix it. Your perspective shifts from ‘How long is this thing going to take?’ to ‘How long do we want to keep investing money into solving this problem’. It also means you aren’t locked into specific solutions or features long-term, you can actually pivot completely after those 6 weeks and work on something different; which is truly agile in my opinion. If you can’t adjust your work to address new legislation within a couple of weeks, I don’t think you’re flexible enough.

So once you have decided which problems you’ll target in this 6-week sprint, the Shape documents get handed to the engineers and they own the creation of it. They are then empowered to build the solution quite independently as they understand the problem and the broad solution architecture. This frees up the Product Manager to do the core of their role, which is to understand their customers both internally and externally. I talk to customers, talk to the other heads of department, talk to sales and start to understand what’s holding us back.

  • What are our competitors doing?

  • What are our customers’ current problems?

  • What are our customers thinking about for the next 6-12 months?

  • What are our customers scared of?

  • What are the business owners/founders planning over the next 12 months?

  • What are our internal objectives and what is our roadmap for growth?

  • Do we have new target markets?

I can then take ALL of that data that I’ve spent 6 weeks focussing on collecting and form it into our product strategy, and new Shape documents.

I believe this system can work for a company of any size but it probably works best for a company of up to maybe 500 people. Once you get to larger companies you often have more bureaucracy which is the death of this system. For ShapeUp to work, leadership needs to give Product-Engineering trust and autonomy.

Advice for early career PMs

Job ads can often be misleading. They will often be vague in the areas that are most important (the core function of a Product Manager like understanding the customer) and hyper-specific in areas that are not important (like can you write a user story or navigate Jira). Product management is about more than just running the processes, so do your best to represent your holistic understanding of a PM’s role.

I also want to see a history of strong interactions with customers. If you’ve worked in customer support then that’s often a big standout experience for me, but any examples you can give of customer-led decision making is a good start. 

Demonstrating experience collaborating with other functions like design and engineering on solutions is similarly important. It ties the work of understanding the problem to effectively empowering your team to find the optimal solution.

Use this article by Ravi Mehta, which calls out the 12 Product competencies, to isolate your strengths and weaknesses. Once you’ve done that, I would focus on 2 maybe 3 of these competencies to improve independently over the next 3 months that match up with the core skills I mentioned above (ie. you don’t need to work on managing up if you’re an early-stage PM.

Resources

Norm
Previous

How I went from management consulting to Head of Product in MedDev
Next

Advice from a Product Recruiter Navigating the Current Job Market