Product Managers Beware!

Managing digital products isn’t always fame and glory. More often than not we see great digital products flop, popular products infuriate end users as a result of a simple changes to the UX (http://mashable.com/2015/06/16/spotify-color-change/) and we see product managers make what are seemingly counter intuitive decisions about the future of their digital product. Oftentimes, product managers deliver a great amount of value but value that’s not initially clear to the end user. I've worked on numerous products over the course of the years and I’ve had my fair share of humbling moments, enough to be able to make more educated decisions and know what pitfalls to avoid. It's always good to share your experiences (and failings) so others can learn from them.

1. Define no Hypotheses 

It’s essential as a product manager that you make testable predictions about your product and users so that you can validate or disprove your assumptions and thus guide your product development.

Let’s suppose we have an acquisition journey as part of our digital product and we go off under the impression that a successful experience means one that gets our users from the starting step to the finish step quickly. We chase speed of completion – the quicker we get them through the door the better. Done, we launch the product and we’re left explaining to our stakeholders why we’ve made no impact to the number of users acquired and all of a sudden we’re polishing our resumes. 

If only we’d simply stated, "I believe it’s most important for users who are looking to apply for a long term loan that speed of completion is most important". We could have then done some quick and dirty testing to verify our assumption and have prevented ourselves chasing a fruitless pursuit. If only we’d used our data to in fact recognise that our conversion currently sucks and that most of our applicants are mobile users and there’s a buggy submit button. Or perhaps our offering is no longer competitive and really it was our pricing model that needed some attention vs. our digital acquisition channel. Oh hindsight.

We could have had a 15 minute fix put in that would have increased users acquired by 5% but here we are sprucing up our LinkedIn profile (luckily not an example from experience!). In product management, all features are simply things that we think can help us move the needle against our outcomes and solve the problems of our users. They're not things we begin developing, they're things we begin validating...what's our data telling us? What are our users thoughts? What is a clear win and can go 'straight to backlog'? 

Features are a list of hypothesis waiting to be validated.

They are things we can arrive at through impact mapping…start by asking ‘why’ (Why are we doing what we do? Why are these the right outcomes? Why are we trying to solve these problems). Then the ‘who’ (who can help us achieve our outcomes/solve these problems? Then the ‘how’ (How can they help us? What capabilities do they possess?) Then the ‘what’…these are ‘features’ but really solid hypothesis begging to be validated. 

What questions are you trying to answer?  

2. Ignore Your Data

Paying lip service to data because the data doesn’t support what you want to see in a product is toxic to your product and its users. When you ignore your data you stop representing and being the advocate of your user and you're likely to make ill informed decisions based on personal wants but not the wants that the data is detailing for us. As product management matures so does our understanding of what makes a good digital product, by testing often whether it be A/B testing or user research and then acting on that learning we can refine and improve our product incrementally and sometimes considerably.

Data doesn’t lie – just make sure you’re using the right data, asking the right questions and performing the right tests. Additionally don’t count on one data source but many. Be careful about catering to the needs of the vocal minority in a reactionary manner - a great deal of people who use surveys will do so to complain about something (especially after a big release). Rarely do users use surveys to sing praise of your excellent navigation or fantastic page load times (unless you do an amazing job!). 

Likewise, just because your data identifies an area of opportunity it doesn't mean it needs fixing/improving now - is fixing a typo on a 404 page valuable? Is cracking an edge case that affects 0.001% of your user base something you can't tackle later down the line? Conversely, are there simple wins you can achieve to make a big impact? Your priority will largely be driven by the outcomes and goals you’re seeking to drive as it’s probable that these are the most important things for good reason. If not, you need new outcomes.

The power of using data is that you can rationalise your decisions and prioritization and ensure you team is pulling in the same direction.

 People Watching/Observational Research

3. Fall Victim to HIPPO's 

HIPPO refers to ‘Highest Paid Persons Opinion’ - it's a slick abbreviation but really what I mean is 'person who shouts loudest'. As a product owner your responsible for ensuring the experience of your users is the best it can be. What goes into your product is your call - with the input and collective knowledge and expertise of others. One of your responsibilities is to ensure what goes into your product isn't a result of someone shouting the loudest. In a similar vain isn't as a result of your own stubbornness to be open to others opinions about priority.

The best way to not be the or fall victim to the 'HIPPO'....or lets say 'LIPO', is to let data do the talking. When your data is screaming the direction you need to take with your product and you have faith in your data then you can use that data to show others (and be shown by others) why the direction your currently taking needs to pivot slightly. No one wants to push forward with something that will frustrate the end user and potentially not go as planned. If you use data to influence others and allow others to bring data to you to inform your products direction then your decisions will be simplified and it's a graceful way to debate what's right for your product. People will be grateful!

Another tip is to test others hypothesis or decisions against yours, let the user do the talking. I've leveraged user testing and split testing a lot in the past to put opinions on the table and with surprising results. Testing will leave you feeling humbled, it made me realise...I don't know it all! What's obvious and logical to you (and even what your data sometimes suggests is right) isn't always what's most practical for the user of your product.

 I just like this image. It's a lego man...cleaning a hippo.

4. Don't Release Often

Deliver user delight/value often! (note - you must be talking in terms of value...measure success in terms of value and not volume). There’s two crucial reasons why releasing often is important. Firstly, we shorten our time to learning – by releasing an MVP we can elicit validated learning’s that inform us as product managers what we should do next. Do we keep our latest feature live? Do we need to refine it or enhance it further or should we pull it from our product? Let your users guide and steer the direction of your product.

Shorten your time to learning.

Secondly, the more often we release the more frequently we deliver value to our users. Have you ever questioned purchasing something because you’re not sure the company your ordering from is secure or operational because they haven’t updated their website for as long as you can remember? Does their checkout process use HTML tables to display the form and pass your private information as part of the URL? Have you ever not purchased a software product because you’re unconvinced by company’s ability to provide ongoing support of that product?

Don’t allow users to use your product with no idea when the next enhancement will be… if at all. One of the reasons Apple is so successful is because you can almost pinpoint the exact date the next batch of enhancements is coming to their product, whether it be a software update or a major hardware overhaul. Make your users feel like their input and feedback is being put into practice to build a more engaged user base. It’s also good practice for your product team – it trains you to get into a habit whereby a release becomes a none event.

5. Don't Define an MVP

I have been guilty of developing products as though I'm obliged to completely overhaul everything and deliver a full fat product exploding with features right from the get go...I like to boil the ocean. However, if you’re not defining MVP’s then you’re missing out on a valuable source of validated learning. An MVP in Eric Ries own words is:

"The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

There's been times where I have seen product managers (myself included) analyse data about their product from their web analytics or social media listening posts and identify features that could potentially enhance the user experience or address a pain point. They've then gone ahead and simply executed it and spent a load of money/time in the process. Then oh no, it seems the solution didn’t quite hit the nail on the head.

MVP's really force us to think about our hypothesis - what assumptions have I made that I need to validate? In my backlog, we don't have features. We have lists of hypothesis that we validate - a validated hypothesis is a feature. We can validate our features oftentimes without even writing a single line of code. 

I think Ian Collingwood shares some nice thoughts on why MVP's are important,

"Before I invest tons of money in developing this product, how can I test if there is enough demand to make the investment worthwhile?

Think about Kickstarter - it's practically as a warehouse full of MVPs. People put up their ideas for interesting products, before they build them, and other people demonstrate their desire by supporting them."

Simply, do yourself a favour and think about what is the least you can launch (even if it's just publishing an idea) to derive some validated learning to inform your next product decision. Sometimes your data and users can't tell you what you need to do next (the anomalous state of knowledge) - you have to make a decision and answer the what and the user will validate if you nailed it. 

6. Don’t Use Your Product Daily

An instant way to lose the respect of your product team is to not use your product daily, it’s demoralises the team. 

If you’re not using the product you own daily then it’s likely that you’re not going to be able to do a very good job of setting a product vision, exhibiting product expertise, inspiring a product team, identifying areas for enhancement. If you lose the trust of your product team you’re doomed or worse…you become dispensable. As a product owner you have to offer something unique to the product team i.e. insights, vision and be the ambassador for the end user. The minute you’re unable to do this you will be pushed to the edge of your product teams periphery and others, possibly not cut out to make product decisions on behalf of the end user, will do just that and you will be held responsible for anything that follows. 

Let’s not forget the obvious, how on earth can you expect to develop something a user will find delightful if you have no more experience interacting with the product you own than your users do? You need to be the power user of your product. You need to be interacting with your product so frequently that you stumble across the hundreds of areas of opportunity that the user of your product, your colleagues, your product team don’t identify. Use your products like you’re testing them. Use your products like your most technologically illiterate of users and like your most savvy.

7. Ignore Competition

If you can’t be a pioneer then you at least need to be a fast follower – we’ve all read the books on innovation. Imitation is the greatest form of flattery. If we aren’t aware of what our competitors are doing then how can we identify our USP’s, areas of opportunity or exploit gaps in offerings that our competitors fall short on? We can’t.

I’m not saying we need to copy our competitors, we’re better than that…we want them to be copying us. We should want to create a new clichés – we’ve all heard people say, “It’s the Uber of X” – we want people to say, “It’s the <insert your company> of X”.

We should always be on the lookout for things we can do to set our experiences apart; opportunities that our competitors don’t recognise. However, we won’t always be the first and if we blindly ignore what the masses are doing it’s likely that we'll be missing something fundamental.  Even if we choose not to follow we should we should always be aware there's something to even ponder about following! Don’t take this as me saying ‘don’t innovate just do what everyone else is doing’, oh no – take risks and dream big but just use your competitors as a sanity check from time to time.

8. Fail to Challenge Assumptions

A great product mentor of mine (and a consultant at a start up I used to be close to) was one who asked purposefully stupid questions because they knew they could exploit the “I’m new here so I can ask ‘duh’ questions” freedom. It was their way of challenging assumptions without offending people by saying, "hey, why do you do things like this" they would instead say, "so what is your test driven development setup … oh you don’t have one...shall we look at implementing one so we can shorten our time to awesome?" 

This will also pay dividends in your design meetings, there’s a psychological phenomenon known as ‘group think’ whereby parties opinions align with the loudest or most influential person in the group. It’s your role as product manager/owner to ask lateral questions, think about how a user would use your product in their least conscious frame of mind i.e. kicking back on the sofa after a hard days work with an iPad in hand or juggling two kids and making dinner while trying to navigate your recipe app. 

Another way to avoid falling into the ‘group think’ pit fall is to assign ‘devils advocates’ in meetings whose role is to challenge people on their decisions and opinions and to ask questions that people might be thinking but may be to afraid to ask. One of the reasons so many people fail to challenge assumptions is because it may show gaps in their knowledge. They fear that if they ask a UX designer why they’ve proposed tabs over accordions that they will look stupid because ‘it’s so obvious’ but the likelihood is that there’s 3 other people sitting there thinking the same thing. The winners in the workplace are those who challenge assumptions and ask questions everyone else is too afraid to ask.

9. Have no Feedback Loop

Sometimes product owners launch products and features without any consideration around how they're going to measure the impact of the thing they are launching or without any means of harbouring insight from our end users. Too many times we've crammed out web analytics tagging into the last sprint of development and ultimately paid the prices when a product launched. 

Perhaps more important is the notion of only having a feedback loop for launched products i.e. those live to our users. This is 2015 – we’re agile and nimble and we can do better than that. Data and insight should be driving every decision we make. We should have feedback loops throughout the design process, we should be putting prototypes in front of our users and listening to their commentary, we should be having a feedback mechanism as a team to discuss ways we can improve the way we deliver. I'm blessed to have the opportunity to work frequently with the users of my products and it's truly delightful and educational. 

You and your team are the experts. You know everything about your domain area, you know the product inside out and you know each other so well you’re practically the Teen Age Ninja Turtles of product development but all of this is wasted if you don’t know what your user actually wants.

One last thing, if you’re going to have a feedback mechanism, whether it be explicit to the user i.e. a survey or hidden to the user i.e. heat mapping their web sessions, make sure that you take action on your insights and feedback; especially if it’s explicit to the user. Users love nothing more than to know that there’s a human behind that survey form and that you’ve listened. To feel like they’ve co created the product they use everyday for the better. It doesn’t need to be big, it just needs to be an enhancement that shows them you’ve listened.

10. Launch Features That You Want 

Let’s keep this short and simple. We’ve all done it, dreamed up the nirvana that our product could be. A perfect digital artifact that is free of all of the bugs and shortcomings we see as a result of interacting with it day in day out. It’s innovative, cutting edge, full of industry firsts and it solves all of our problems and makes us look awesome! Great.

Are you becoming the end users HIPPO? If so, abstract yourself and every day ask, ‘Am I doing the right thing for the end user or am I doing the right thing for myself/own needs? As a product manager/owner it’s your duty to make sure that what you’re doing is addressing your user needs and delighting them and not doing what you think is cool.