12 things I’ve learned from the Head of Product role

It’s been a busy, roller-coaster of a time for the last three years, but from the end of March I’ll be leaving my role as Head of Product at Emerald Publishing. The title and role can be interpreted in many different ways across disciplines and industries (as Marty Cagan points out in Inspired), but there are some universal truths I share here which I hope will help others in their HoP journeys.

This post functions not only as knowledge sharing, but partly as handover notes to my successor, and partly as a brain dump to get everything out of my head before the next adventure. As such, it may not be the most structured post you read today — but should be worth referring to at some point in the future. So without any more ado, let’s go:

1. NIHITO
   OK, so I’ve got the guys at Pragmatic Marketing to thank for this one, but this is one of the most important things I’ve taken away from their training courses: Nothing Interesting Happens In The Office. In other words, get out of the office and get talking to your customers, potential customers, lost customers, non-customers. People talk a lot about ‘knowing the market’ and doing user research in certain ways, but unless you are out there talking to people about their processes, workflows, problems, working days — you’ll never get to know how you can help them. You can refine your interviews/observations/questions as you go along — just make sure you’re doing something and make sure everyone on your team has a clear and visible expectation of how often they should be out (once a month, 4 hours per 4 weeks, half-a-day every 6 weeks). Whatever it is, make it obvious and accountable.
2. Love the problem, not the solution
   It’s all too easy to get to solution-eering before we’ve fully understood the problem. This then changes focus of the delivery teams from addressing the problem, to getting an identified solution built. What can we say at the end of this process? We’ve built a thing — and may be inclined to cross it off our roadmap.
   However, if the problem is articulated as the roadmap item, we can only cross it off when we know the problem has been solved. This makes us focus on the outcome, not the output. Roadmap items should be lists of problems, not solutions.
3. Pencils before pixels
   Another easy trap to fall into is developing an interface to your solution in the sprint, or just before it, without checking this with your intended users. Sure, we can iterate on it after launch, but it is much easier at the user research/interview stage to propose something to the users there and then by drawing it out on paper. It doesn’t have to be perfect, but it will identify the key pain points and how the user expects to see them resolved. Always take a pad and some Sharpies with you on user visits. Invite the users to draw with you — even deliberately doing something wrong so that they get involved by correcting and putting something else in there.
4. Build a customer feedback machine
   Where does your market and product feedback come from? Sales? Marketing? Customer Support? Sure — it should include those, but be aware that they are proxies and as such may have been filtered and presented to you in a way which is not completely unbiased.
   Go and work in customer support for a week. Go and shadow a sales rep. Go to a major conference and stay on your stand for the duration. This is how to get unfiltered feedback. You need this to build an evidence base for action and prioritisation of the backlog. Where else can you get direct feedback? Analytics is one. Quant surveys is another. And you’re doing a customer visit on your own once a month, right?
5. You can only iterate after launch
   It seems obvious, but you can only improve your product-market fit with market and user feedback once the product is launched. Up until that point, you are developing in isolation. Informed isolation I would hope (if you follow the points above), but the proof of the pudding is when you release something to the outside world. And as this is the most important value driver to improving your product, you really need to get something out of the door quickly and then — and this is the important part — make sure you have time and resource to take the market feedback and improve your product. There’s no point in releasing something and then moving onto v2, or another product entirely, if you can’t take the feedback and do something useful with it.
6. Hire team members, not individuals
   A product team is a collection of individuals, and as such each person will have a set of skills and attributes that are different to the next person. Your job as head of the product team is to view the team as a whole and appreciate where your strengths and weaknesses are as a team, and hire appropriately. For instance, if we were to hire a new UX designer, and our UX team was strong in user research, testing, psychology and journey mapping — but weak in UI, then it’s clear we need our next hire to be strong in UI. That way we embrace people’s specialities, without making them feel like they need to become all-rounders. This person then becomes a key member of the team and has improved the team’s utility to the organisation. A simple win-win.
   Remember your job is to create an environment where your team can flourish and grow and depend on each other.
7. Co-develop with internal stakeholders as well as external users
   Something I wish I’d appreciated sooner, is the need to get internal buy-in on product development as well as optimising solutions for our customers. Internal cultures can be slow and behaviours ingrained, and your product may require some change in how things are done in departments across the organisation. So at the point you are co-creating drawn prototypes with customers, you should also be doing it internally with all your colleagues and stakeholders who may be affected in some way. You will give them a heads-up that something new is coming at some point soon, but also you may get valuable input into how to make integration or development easier. Plus it’s fun!
8. This is Day 1
   Jeff Bezos’ mantra about this always being Day 1 is an eloquent extension of the sentiment don’t rest on your laurels. As product managers we need to be constantly learning, listening, questioning, and adapting. When you stop doing that, irrelevance and slow decline to death are inevitable.
9. Be accessible
   In both ways. Firstly, try to make yourself available to your team as much as possible. That might not always be in person (indeed, for remote teams, it’s unlikely to be the case), but give everyone your mobile number and WhatsApp details in case something can’t be handled by Slack or email. 1-to-1s are valuable for some, but can become a box-ticking exercise in some cultures. Use them if you both get value from them.
   And secondly be accessible in the accessible sense. Accessibility is an enormous boon to an increasing proportion of the world’s web users, so make sure your product has accessibility baked in from the start. Test with users with low vision, anxiety, dyslexia, motor issues. Don’t try to add in accessibility at the end — it never works properly.
10. Celebrate success
    Teams love celebrating success, but frequently feel like they need permission from someone to do so. Be proactive in suggesting even minor wins are celebrated in some way. Buying cakes for the team for small wins, to trips away for large ones. Make sure we don’t take success for granted by celebrating when it comes our way.
11. Agile is a state of mind
    If you’ve lived through an ‘agile transformation’ you’ll know that — even done well — your company can only do so much. Changing workflows, seating, hardware, software, office space, environment — yes, all important. But the hardest part of any transformation is getting inside peoples heads. If they’ve always worked one way, getting them to think about working another way is hard. Think Big, Start Small, Act Quickly. Easier to say than to embed in people’s heads — until they see results by people who have embraced that philosophy.
12. Decide quickly with just enough info
    A key follow-on from this, is that if you want to move quickly, you don’t need to be 100% sure about something. Is evidence accumulating about a market trend that you think will become significant in the future? Run a small scale experiment to see if you’re right.
    Is the decision reversible at some point in the future? Go with your gut now. Remember, if you don’t ship, you can’t iterate, and if you’re not iterating, you’re not optimizing for market fit.

I’d love to hear from other product leaders about what their takeaways have been from their experiences.