Some (hopefully useful) Product Learnings: Product Pointers for newbies and reminders for the old guard

Back when I started in Product (2009), there wasn’t much of a formal Product industry and community in the UK — Mind the Product hadn’t been founded yet and I was working as a ‘Web Development Manager’ after convincing the CEO to give me a shot at delivering the company’s flagship digital service re-platforming effort (long story short it involved hijacking and chauffeuring the CEO around to make sure I got some air time — I was that keen to get into Product!).

Whilst Product as a discipline and community has evolved much and the technology we all take for granted now would have been almost unrecognisable then, some things haven’t changed at all — Mostly because people are still people. I thought I’d finally write down some of those things so they might help those new to Product, or act as useful ‘ah yeah’ reminders for those that have been around for a while.

Tip 1: You don’t need to understand everything (but the more you do know helps)

Starting in Product can be a daunting experience, from day 1 you’re the mini-CEO of your product responsible for its success, leading a group of Engineers and needing to convince stakeholders from up and down the tree that you’ve got a handle on things. You’re involved in business strategy, technical architecture, user experience and other specialist areas and expected to contribute and ultimately make the final call. The things that you think you should know are endless and you feel like you’ve got to swim full-pelt through a sea of information or sink in it all.

My first position was like this: On day 1 I was handed the reigns and (because it was 2009) ‘requirements’ documents about two feet high (yes, they were all printed out). My first task was to make sense of all these requirements that had been written by BAs that had since left, figure out what had been cut to code by Engineers that had since left, and figure out how we could save a re-platforming effort that was already months overdue, and millions over budget. It was overwhelming to say the least.

Those first few months I learnt a lot about the pit of despair, living, breathing and even dreaming about the work needed, getting questions left, right and centre from brand new Engineers and stakeholders that had long ago lost trust. At first you’re scrambling to make sense of it all, but then (over time) things start to click into place, you don’t need to be the Engineer, the Designer, the Digital Trader. It’s your job to not be these worlds, but to bring them together so everyone can achieve their goals that ladder up to something bigger. These people are always going to have more time, attention and most probably skill than you to be great specialists, but they need someone sitting in the middle helping to steer and deal with the natural tensions that come out of having a group of people that do very different things with different goals. You are that person.

That’s not to say you don’t need to know anything about what they do, in fact if you come from a background in one of these areas it’s a good start. But it’s not about being the specialist or having to blag your way through meetings with them because you don’t have the knowledge, it’s about appreciating their point of view and needs, helping them bring their best to the table with the other specialists needed. Product Managers that say they suffer from the Imposter Syndrome in my view have missed this — You don’t need to know everything that your Engineers, stakeholders etc know, you need to be able to put on their hat and create an environment, roadmap etc that allows everyone to focus on the big vision and achieve their different goals too. Don’t try and blag your way through a meeting — the best Product Managers I know frequently put up their hand to say they don’t know and then go find out from the people that do (that’s what learning is all about). And this becomes an ever more important skill the higher up the Product tree you go.

Tip 2: It’s all about people (people shape the processes and the product)

Odds are someone is the end user of your product. And the people that create it, well they’re people too (sometimes even the same people). You work at the centre of a people industry, that happens to utilise technology, software etc. The things that can add the most value and are also usually the biggest cost are people. They’re at the heart of everything we do (and even central to the Agile Manifesto). They shape processes, cultures and whole organisations. They leave their inherent watermark on everything they do, including the products they create (and sometimes not in a good way).

I didn’t start out from a technical background, with an MA in experimental Psychology I was always interested in people and was advised to move into HR since that was apparently all about people. I soon moved out of HR and into Product as I wanted to build things (products, relationships) as opposed to fire people and act through line managers (sorry to any HR readers but it wasn’t for me). And I wanted to experiment and get into the data, which there were limited opportunities for in HR (plus experimenting with your colleagues isn’t always ethical 😊).

So I might be a bit biased, but if you can crack the people bit (see Tip 1 above) and understand what both people on your team and customers need, you’re well on your way to becoming a great Product Manager.

Tip 3: Beware the MVP (you maximise value creation)

MVP… the saviour or the dirty term. Debate. The term historically comes from the lean start-up movement, largely in reaction to slow and wasteful practices associated with waterfall development. Don’t know if your product will float with customers? Deliver the minimal thing viable to get feedback and then iterate from there.

Sounds great in theory, and still has its place — for example when you think there will be demand for a product but you don’t really know until you try it out (you’re not sure you know your market and may need to pivot quickly). However, it has also become a synonym and flag pole for the feature shippers, those that define a good job by the speed at which new features can be landed with customers (by delivering a minimum set of a great many things).

It can be very tempting to aim for maximising feature deployment, especially if senior stakeholders think this way and it’s difficult to prove your worth another way (more on that in Tip 4). However, it isn’t your job as a Product Manager to ship features, it’s to deliver value. And further than that, it’s to maximise the delivery of value, to create a continuous stream of value by prioritising the right work (epics, stories and the like) delivered in the right way (technically defined with Engineering) at the right time.

So think MVC instead (Maximum Value Creation) — How do you maximise the value you can produce from the time and resource you have. Some would argue this is just like the old approach — You’d end up spending more time delivering too much or wasting effort. But if you aim to continuously maximise value creation, you’re constantly scanning to see if the next thing has more value and if what you’re currently working on has diminishing returns — You’re continually making cost / benefit trade-offs on the roadmap so you can deliver as much value as possible as quickly as possible. This is also not incompatible with the MVP concept, it’s just creating an MVP is one possible way of delivering Maximum Value Creation that is appropriate in certain situations, i.e. when you’re really not sure and need to test your assumptions quickly out in the wild (and probably a way you will not use very often if you can crack Tip 4, unless you’re in the habit of pivoting products all the time).

Tip 4: Prove your worth (measure value)

As a Product Manager, you help create something that is complex, and wrapped in a constantly changing ecosystem where there are many dependencies on multiple moving parts. For example, you could change an eCommerce site PDP (Product Details Page), as you’ve decided that prioritising the content on the page and applying some UX best practices will help to increase add to cart (and ultimately conversion + profit). You follow all the design best practices and get the update out, sit back and wait for the uplift in data to come in. But it doesn’t. Why not? You don’t know. It should have done. You’ve done everything by the book. But didn’t have time to test. Ah.

Testing should be the default mindset of successful Product Managers. You could have missed something critical in the build, be surprised by what’s actually important to customers, or simply an external event could have trashed your data (maybe marketing started spending shed loads directing poorly converting paid search traffic to your PDPs).

Customer feedback is a powerful thing (which is part of the popularity of the MVP — you get early feedback), and it’s your job to validate your product in the most effective and efficient way at each stage of its creation lifecycle — It’s the way you can continuously validate you’re delivering the maximum value. That means selecting the right UXR to validate your product, plus A/B testing / MVTing it out as well as monitoring the analytics. It’s not enough just to deliver what you think is valuable, you need to validate that and then measure it too. It’s only by proving your worth (by showing that the product development team deliver more value than they cost, by measuring actual value added in terms of the metrics and currency your company works with) that senior stakeholders will give you the space and the freedom to make what you already know are the best decisions for your product.

Tip 5: Just doing a great job isn’t enough (but doing a great job is a great start)

Finally, this is more a general reminder that could apply to any job that has to deal with intangibles where your success is defined by the collective effort of many, many people, and maybe not all stakeholders understand what you do: Doing a great job is the foundation, but often you need to make that clear to the people that need to know you and your team are doing a great job. This means self and team promotion, with all the brand marketing that goes around it. If you’re doing a great job, make sure the right people know you (and the team around you) are. If you don’t, they might wonder why you aren’t, especially when everyone else is doing it!