Lessons in Product Management through unemployment
I’ve been working as a Product Manager for about 5 years now, all of it for a single company. In that time I’ve learned a great many things, both from the very smart people I’ve been fortunate to work with, and also from more formal courses and seminars.
Now some 38 interviews and a couple of job offers later, I’ve been shocked at just how much I learned throughout the process; about being a Product Manager, and the discipline of product management itself.
Document everything
Successes are great for morale, failures no so much, but still a good opportunity to learn. Either way, all of them may be good talking points to bring to interviews or new companies. The problem for me had always been that once dealt with, they weren’t really relevant to me, and if I ever needed to refer back to them I had internal documentation to look at. Unfortunately that all belongs to the company you work for, and as a result not available once you’ve left. What I do now instead is keep a personal log of successes and failures (and any learnings). Useful topics include overcoming difficult technical problems, dealing with difficult interpersonal situations, and particularly important, tracking impact on significant metrics for projects you’re responsible for.
Blog more
Related to the previous point, it helps to blog or post about significant events in your career. Not only does this provide a more permanent record of events for future reference, it forces you to describe those events in a more narrative fashion than would be needed for any work-related purposes. This makes for an ideal format when you relay the outcomes and learnings to people unfamiliar with the situation or context. Lastly, it also allows people outside to provide feedback and different opinions on what happened.
- Metrics and counter metrics
- Identify your strengths and weaknesses
- You can do a lot with limited data and good assumptions. Estimate seemingly impossible scenarios.
- Formalise a structure for innovation
Analyse products you love
“Tell me about a product you like” was a question that I expected to be asked at some point (although it only came up for me once or twice), and didn’t give it too much forethought because it seemed easy to answer. The first time I was asked, I really had to think. There are lots of products I could point to that I love, but not so many that I could really articulate the reason that made them so great, on the spur of the moment.
Now I’m trying to think about products more and capturing those thoughts in some way can lead to some interesting insights. Not just what’s good about them, but what could make them even better. Set a high bar for yourself and bring that to your work.
Analyse products you despise
Similarly, it helps to think about products you don’t like (there are probably many…) What is it about them that’s not great? What are the parallels with products you may be working on? Why might it be like that, what could the trade-offs have been, and how might different trade-offs have led to a different product?
I always think about the Apple TV remote (not the latest one, mind), and how much frustration it caused me. The biggest problem stemmed from it being utterly unusable in the dark, where it was tricky to tell if you were even holding it the right way up. I suspect that the trade-off there might have been “form over function”, in an effort to make it stand out against other remotes you might have in your living room.
Get to the point
When I first started interviewing, I balked at the idea of having to spend 30–60 whole minutes convincing a stranger that I was in any way competent at product management. But in reality, I often found myself feeling like there wasn’t enough time during the meetings. Getting to the point sooner means there’s more time for analysis and discussion, which are actually the interesting and useful activities.
This is true outside of interview settings of course– any time you are trying to convince a stakeholder that your product ideas have merit.
Use build-measure-learn
I reworked (or “built”) my CV several times. Each time I measured its effectiveness based on the responses I had (which were largely binary- yes we want to speak to you to find out more about you, or no thanks (or just tumbleweeds, which amounts to the same thing)). In doing so, I iterated my way to a CV that resonated better with more recruiters, rather than getting disheartened that it was landing well.
Product works differently everywhere else
Some companies do a “Product Sense” type of interview, asking you to talk about some hypothetical scenario and what you’d do to “design a solution”, which I had mixed results with.
Part of my issue was that, I’ve had it drilled into me to avoid coming up with solutions. That’s what designers are for. So whenever I had an interview question that began with “how would you design a solution for…”, it made me cringe, and worry that (to quote a good friend of mine) “they think that designers will come in later on to draw the pictures after the real design has been already decided”.
In addition, I’m just not very good at hypotheticals generally, and so when I was asked to describe how I’d design a new travel experience for example, I’d get tied up in knots because I don’t feel like I’d ever get myself into a situation where that’s the kind of work I’d be involved in.
The companies asking these questions though, tended to be the gargantuan ones that see opportunity in every facet of life, and so were undoubtedly looking for people who could do the same. Me, I prefer to excel in a couple of specific areas rather than be a generalist, so eventually I started to see those questions as red flags for me. This is particularly true for interviews where the interviewer is not actually the hiring manager.
Define what data-driven means to you
People would be dissatisfied to my answers to variations of “how have you used data”, because they’d inevitably be expecting to hear anecdotes about the times I A/B tested 50 million people on the colour of a button, except I’ve only ever made software people pay for and which doesn’t have that level of scale. So I’d talk about the insights I’d gained from conversations or observations and the interviewers would wonder what the hell I was talking about.
Since making that mistake many, many times I started prefacing my answers with the context of “well our platform and level of scale didn’t allow for that level of quantitative analysis, so here’s what I did instead”, which proved to be more successful. And really, when you think about it, you probably use data to make decisions a lot more than you realised. At one point I was making a presentation about an onboarding experience I rolled out, and digging through my old notes it was clear that there was a lot more analytics data I’d leveraged than I’d remembered.
Document everything. Really.
This was so important I need to mention it again. It’s helpful to have a record, but it’s even better to have a concise summary of a learning. Having a book on your shelf is one thing, having a single profound learning from that book readily available is even better. Even having notes from various courses and books I’ve read isn’t enough for me; something I’ve learned is that having them categorised by topic is extremely important; so for example all my collected notes relating to growth are in a single place, regardless of whether they came from a discussion on growth or not.
For one thing, it helped me realise that I have a great deal of viewpoints and perspectives related to decision-making and prioritisation; something I felt that I struggled with in a number of interviews. For another it helped me to make my thinking and approach more structured and accessible. During my most recent series of interviews, I felt confident answering pretty much any question that was thrown at me, given they would tend to be about a small number of themes:
- How do you prioritise within a project?
- How do you prioritise across projects?
- How do you work within your team?
- How do you say no to things?
- How do you use data?
- What do you think Product Management is?
I had talking points ready that I could use to illustrate any of these when they came up (and in some instances I would preempt some of them, such as talking about how I use data as a way to say no to things).
Doing this forced me to think about how I actually approach these different things, and made me realise that some of them could be more robust going forwards. I learned a lot about different frameworks, and I also went back to approaches I’d tried earlier in my career and reevaluated them against more recent situations.
Interviewing for any role is often hard or even soul-destroying, particularly when you’re under financial or other pressures. Throughout the process of looking for a new place to hang my hat, I held in my mind the quote about success being “going from failure to failure without losing enthusiasm”. There’s a tendency to want to succeed in every interview, either because it takes the pressure off, or for some sense of validation. But looking back I can see that many of the positions I’d applied for simply weren’t a good fit for me, either because it wasn’t the right culture to nurture me, or because I lacked the right skills or knowledge.
Probably the biggest learning I had was that I’d gotten way too comfortable in my previous role. My rate of learning had sharply declined, and I probably wasn’t competitive compared to other people looking for similar roles. In recognising that, I was able to approach potential jobs differently, knowing what would be a good fit for me, but also where I could bring something valuable to the company.
One of the common questions I was asked was how I define Product Management. I actually stole this paraphrased definition from Brandon Chu, but it really resonates for me: “Product management is ultimately about giving customers better and cheaper ways to achieve their desired outcomes”. My approach to interviews now is likewise trying to understand whether the company will help me achieve my desired outcomes, but also whether I think I will help the companies and teams achieve theirs.