8 things I learnt about Product Management

The art of the determined explorer

Being a Product Manager is not a straightforward role, not by a small margin. The sheer scale and variety in the role means no ‘one size fits all’.

Product Managers come from all walks of life, and there is no single right way of practising this misunderstood discipline. How the role plays out depends on a number of factors:

  • The size of the company
  • The culture of the company
  • The organisational structure of the company
  • The background of the PM (could be ex-developer, designer, marketing, business analyst, project manager etc)
  • The surrounding qualities within the team itself

There is a lot of talk in the industry about Product Managers being mini-CEOs of their products. I am not convinced it is that straightforward. Some Product Managers may have commercial experience in managing a P&L account. But others may have come from a development background and are more geared toward implementation, leaving the P&L to the commercial team. Ultimately, there is no right way, and you should do what works best for you and your company.

“Product management is a weird discipline full of oddballs and rejects that never quite fit in anywhere else.”
—Ken Norton (ex-Google PM)

At the very least, I thought it would be useful to document the experiences I have endured over the last 2.5 years of being a Product Manager. I am by no means a qualified expert in the field. My background is Project Management (4 years) and previous to that, web development (a long time ago now it seems!). I still have a lot to learn.

During this time I have documented my top 8 bits of wisdom, along with examples, and my own personal reflection on misconceptions about standard product management techniques.

1) Constantly ask: “what problem am I trying to solve?”

“Customers don’t care about your f#$%*g solution, they care about their problems.”
—Dave McClure

Product Managers need to focus on the problems and opportunities, and not the solutions. Product Managers are the ‘what’ and ‘why’. Developers own the code base, and they should tell you ‘how’ to build it.

For example, you shouldn't be doing a responsive website because it is trendy and everyone is talking about it on Twitter. Customers don’t even know what a responsive website means, and don’t care either. As a Product Manager, you need to identify trends in advance to counter-balance problems that might arise in the future. It might be the case that you see mobile traffic rise from 8% to 25% over the past year, but your website does not cater well for mobile users. In usability testing, you might have seen people struggle using the site on a tablet. These are the real reasons for identifying the problems and why you should be tackling them. Leave the discussion on implementing solutions to the designers and developers, who are the experts in how to build things.

It can work on smaller day-to-day activities too. I remember a designer once asking me that they wanted to add animations to some of the images on the site, at a time when we had plenty of other priority stuff on. I remember taking a pause, and then asking ‘what problem are we trying to solve by doing this?’. The response was along the lines of ‘it helps bring a bit of character to the page’ but actually after a bit of discussion together, we came to the conclusion that having animations could distract users from the important information on the page. As a Product Manager it is good to question morals, to fully understand the real reason for doing something, which in turn helps focus attention on priority work.

2) Focus, focus, focus.

“If you chase two rabbits, you catch none.”

One of the big lessons I learnt was being overly ambitious, to extent that we were trying to do too much without achieving much at all. For anyone that has a vision, it is easy to be ambitious (and try and do everything at once), but hard to be realistic about what can actually be achieved. The best way to overcome this is to simplify and prioritise your roadmap, so you are achieving greatness, step by step.

I know there are many examples on the web about Apple’s success, and it is become a little clichéd to reference them. But I can’t help myself, after all, Steve Jobs was a fantastic example of a Product Manager. When Jobs returned to Apple to help a failing company, one of Steve's first prerogatives was to reduce Apple’s bloated computer product range from about 40 to just 4. He achieved greatness by focusing on his core products, making them awesome, and then moving on. The rest is history.

One of Jobs’s great strengths was knowing how to focus. “Deciding what not to do is as important as deciding what to do,” he said. “That’s true for companies, and it’s true for products.”
—Steve Jobs biography by Walter Isaacson

There are plenty of other examples of web companies who focus on 1 product, but do it really, really well.. Think Mailchimp and Airbnb amongst others. And a more recent example of a company that has learnt about the importance of product focus would be that of 37signals. Check out their story here: https://37signals.com/

It is a lot easier said than done however, as there is inevitably a lot of people with a lot of ideas, with not enough people to be able to do them, and a constant stream of BAU / bug fixes on top of that. As a Product Manager, you have to be rugged, not be afraid to say ‘no’ at times, but ultimately be the person to help steer the ship by constant collaboration with the team. Which nicely brings me to…

3) The importance of collaboration

“If you want to go quickly, go alone. If you want to go far, go together.”
—African Proverb

This is an obvious one for any Product Manager, but at its essence, this has to be one of the most important factors to get right. Your role is to be the interface between all areas of the business, whether that be marketing, commercial, the CEO, UX, developers, customer services, call centre, etc. Ultimately, it is your role to help your team (and company) ship the right product to your users.

But it goes much further than just at the Product Manager level. It should be encouraged that developers work together as a team, and not working in silos on separate projects (again, back to the importance of focus). There should be direct interaction between designers and developers right from the start of a project, rather than a ‘waterfall’ approach of handing designs over to development to build. And marketing / commercial teams should be involved, perhaps not as regularly as the product team, but in the constant loop so all bases are covered.

Why should this matter to you as a Product Manager? Well, the PM should be setting the ethos for the whole team; organising and inviting the right people to the relevant meetings, and ultimately making sure the product is fit for purpose. Listen as much as you talk. Act as the mediator in the event of conflicting interest. The amount of times I have seen a project fail because it is not what the user wanted, or someone assumed something which led to an issue further down the line. All of this can be avoided if the most basic of collaboration happens, preferably more than just sending an email.

4) Use data, but use it wisely and effectively

“We leverage data, but aren't slaves to it.”
—Satya Patel, ex-Twitter / Google PM

Big data still seems to be on trend at the moment, with a number of companies relying on data to make the product decisions. I see this a lot recently and I agree with a majority of it, but I don’t fully endorse a single minded approach. My take on it is that it is great to have loads of data so long as it is accurate and used wisely, but it should not be the ‘be all and end all’ of product decisions. Product Managers should be utilising both qualitative and quantitative techniques to making product decisions, along with a healthy dose of ‘common sense’.

For example, when you are looking at data within Google Analytics, you have to be aware that you are looking at a snapshot of ‘what’ is happening to users on the site. What this is not answering is ‘why’ this is happening. Why are more people clicking through to that page? Why is the bounce rate so high here? If you think you know, you are probably speculating. By using qualitative techniques such as usability testing, you are watching people’s interactions on the site and identifying trends in user behaviour, which in turn will explain why they are clicking on that button through to that page, instead of the one you intended.

I have had the pleasure of working in a couple of teams that displayed polar opposite approaches to using data. One team were very much ‘lead from the heart’ with their product decisions; their argument was that they have the specialism in the industry to know what is best, and it was their role to pave the way to show how things were done. They did not rely on research data at the beginning of the project; they were quick at deploying updates but they did measure post-launch to evaluate effectiveness. Build, deploy, and measure. Heart over head.

In contrary, I also worked in a team that worked continuously on analysing data prior to starting a project, during the project and also after the project had been launched. They were totally obsessed about data. There seemed to be a lot more discussion about things even before the build started but consequently they had more data and metrics to prove assumptions. Head over heart.

Ultimately either approach has its benefits and disadvantages, and is likely to depend on the culture of the company as to which method is used. My concern with using too much data is that it can lead to analysis paralysis syndrome; over-thinking and discussing when you could just be getting on with the build and start capturing sales sooner.

It must also be recognised that there are other external factors outside of data that could have an influence on product decisions, for example design or brand related factors. Data may prove that having pink buttons is the most successful CTA — but does this fit in with brand? Is it really worth having pink buttons for a 0.01% improvement in click through?

You also have to question the reliability of the data. How much of the data is being affected by competitor behaviour, or by your clients, or by market changes, or by traffic/SEO, as opposed to changes on your site? Are your data platforms 100% rock solid? Things can get complicated.

Data is incredibly powerful and should be used as guidance on making decisions, but not always the final say.

5) Be customer focused, not customer lead

“If I had asked people what they wanted, they would have said faster horses”
—Henry Ford

As I mentioned before, usability testing and similar techniques can be used to help steer product decisions. What I mean by this, is to understand user behaviour when navigating the site, and to identify trends in usage. Admittedly you are testing small sample sizes at a time, but that should be enough to identify similar trends. It is likely that 2 or 3 users will find the same issue when you present a scenario to them.

What it is not about, is to pick up on people’s opinions. ‘I don’t like the colour of this button’ — these types of responses are purely subjective. The design teams are far more capable at making these decisions than a user, plus there could be company brand commitments. A lot of customers don’t actually know what they want, but that doesn't stop them from having an opinion. Likewise with receiving customer service emails — inevitably there will be a lot of crap you need to filter out, but at the same time, some real good nuggets of information.

More information can be read about this on the Mind The Product site: http://www.mindtheproduct.com/2014/02/be-user-centered-not-user-led/

6) Is viable enough?

viable ˈvʌɪəb(ə)l
1. capable of working successfully; feasible.

OK, this is a bit of a touchy subject for me. For starters, I dislike the term ‘Minimum Viable Product’. Why? Because your product shouldn't be just ‘viable’, it shouldn't just be ‘feasible’. It sounds to me like someone saying: ‘That will do for now’.

Ideally, we want to make the ‘Minimum Desirable Product’ — something that has a quality finish whilst at the same time being usable for customers, and done in a timely fashion.

The principle of taking a big piece of work, breaking into smaller chunks, and deploying in a succession of iterations, makes sense to me. But it has to be built with the users in mind. There is no point releasing something if users can’t, or won’t, use it. Reputations are at stake here, and that often gets forgotten about. The question we should be asking is ourselves is: Have we delivered delight to users?

An example of this is when we were developing some internal reporting tools to our commercial teams. In this instance, the commercial teams were our customers (non external facing). Whilst the developers went about their business building and deploying, after the first iteration they sent a mail round to the commercial team with a link to the tool. Essentially, it was a very, very basic version of what was requested — a couple of dynamic graphs with little control over filtering the data. ‘Is that it?’ says the commercial team. And to add further insult to injury, it was buggy and lacked finesse. It almost felt as if the development team were trying to showboat about how quickly they could get something deployed, without actually taking into account the needs of the user. The product was simply not usable.

Whilst the concepts are sound, it is normally the execution that fails. As a Product Manager, you need to establish with the development teams and the user what is good enough to be the ‘Minimum Desired Product’, and do what you can to help mediate that.

7) You have to think big picture, but also care about the finer details

“Be faithful in small things because it is in them that your strength lies.”
—Mother Teresa

You are passionate about your product, right? And so you should be. If you care deeply about products, you also deeply care about the small details.

In traditional management theory, it has been widely written that managers should only care about the higher level aspects whilst leaving the detail to the people doing the actual work. I actually disagree with this statement, and rather managers should deeply care about the intricacies of the product. Think back to Steve Jobs again — he had a great visionary attitude but at the same time cared greatly about all aspects of the product, no matter how big or small.

What can you do as Product Manager to accommodate this? Ultimately lead by example, and get your hands dirty; help out with wire-framing, QA, copy writing etc. Take interest. Make sure everything is spot on. Being engaged with your team shows you care, and willing to go above and beyond the call of duty, and they will respect you for that.

8) Be a determined explorer

“Success consists of going from failure to failure without loss of enthusiasm.”
- Sir Winston Churchill

Product Management is more about an attitude rather than set of skills. It requires the determination to succeed; to help drive the product forward, to help get things done, and to bring a level of pro-activity and positivity to the team. And you must have the enthusiasm of an explorer; to be naturally intrigued about the product, the market, the competition and to inspire others with a product vision.

Things aren't going to go perfectly all the time. You aren't afraid to fail every now and then, so long as you are learning from the experience and moving on. There will be battles along the way. A lot of battles. The first year will no doubt be stressful; trying to identify how you fit in, what the product does, what people want from it, where it should go, what the competition are up to. It is by no means an easy ride, but it will sure as hell put a smile on your face when it does!

Useful links

Product Manager manifesto: http://venturegeneratedcontent.com/2013/07/11/we-are-product-managers/

Interface to Business, UX, and Development: https://medium.com/p/63c09a43d0ec

How to hire a product manager: https://www.kennethnorton.com/essays/productmanager.html

3 key skill sets that make a successful PM: http://blog.kentonkivestu.com/3-skillsets-for-PM-success

Product Strategy means saying No: http://insideintercom.io/product-strategy-means-saying-no/

How Google makes a roadmap: https://medium.com/bringing-the-donuts/99a4d014f942