10 Ways To Ruin Your Product

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 and we see product managers make or get forced into making counter intuitive decisions about the future of their digital product. We’ve compiled a short list of sure fire ways to ruin your digital product — we’ve seen it all too many times, make sure to avoid some of the pitfalls listed below.

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 and 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 blindly go off under the impression that a successful product 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 were left explaining to our boss 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 composition 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 recognize conversion currently sucks and that most of our applicants are mobile users and there’s a buggy submit button. 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.

2. Ignore or Don’t Use Data

Those people who pay lip service to data because the data doesn’t support what they want to see in a product are poison to you and your product. These people don’t represent the user and make ill informed decisions based on their personal wants but not the wants of what the data is telling them.

In today’s age, where we have a solid understanding of what makes a good digital product, by testing often whether it be A/B testing or user research and 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 — if 90% of your survey results are users complaining about edge cases or trivial things such as the design or slow loading of your 404 pages you shouldn’t necessarily respond to that as your first priority. If you have a 50,000 person user base and only receive 100 survey results a month the you should be reactionary. The majority of people who use surveys do so to complain about something or call out something that’s sub optimal, rarely do users use surveys to sing praise of your excellent navigation or fantastic page load times.

If your web analytics is telling you that 30% of your traffic is bouncing off the final step of your checkout journey — I would probably say that’s your priority. Your priority will largely be driven by the outcomes and goals you’re seeking to drive as it’s probable these are the most important things you’re trying to achieve for good reason.

The power of using data is that you can defend your decisions and prioritization when you have lots of stakeholders and top management chasing you up to make changes that benefit them and their business objectives but not those of the user — or the the majority.

3. Fall Victim to HIPPO

When the ‘Highest Paid Persons Opinion’ (HIPPO) dictates what goes into your product you have a problem and it’s likely you’re not being allowed to fulfill your role as a product manager/owner. There’s nothing more infuriating for a well grounded, data driven product manager/owner to be undermined by top management.

The issue is that it’s hard to say no to someone who provides your funding or is in charge of your appraisal. However, there’s ways to not fall victim to HIPPO and tools that you can deploy to say no gracefully without it feeling like you’re really saying, “Bitch, please!”

Your first tool per above is to use data — 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 your HIPPO why you may disagree with their wants from your product.

No HIPPO wants to push for something to happen and then be left red faced when it doesn’t pay off. If you show them data to influence their decision they will hopefully be grateful that you gave them a heads up and helped them to make a better product decision…even though we all know it was really you.

Another tip is to test their hypothesis or decisions against yours, give them a false sense of choice. We all know your idea is going to win because it’s anchored in your data but why not put that to the test? Do some user research or run an A/B test, it’s a low risk way of putting your HIPPO’s idea into a user hands and the only real way to comfortably be able to dismiss or accept their ideas.

4. Don’t Release Often

Deliver user delight often! There’s two crucial reasons why not releasing often is important. Firstly, we shorten our time to learning — by releasing an MVP we can elicit validated learnings 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 not convinced by company’s ability to provide ongoing support of that product?

Don’t be one of this product owners where your users blindly 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

The amount of product owners that I’ve seen develop their products as though they are obliged to completely overhaul everything and deliver a full fat product exploding with features right from the get go is beyond me. 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.

Too many times product manager read data about from their web analytics or social media listening posts and identify features that could potentially enhance the user experience or address a pain point and then go ahead and simply execute it and blow a hell of a load of money in the process..and then oh no, it seems they didn’t quite hit the nail on the head. One example of this that I’m familiar with was when a product manager launched some pretty major updates to a digital wallet. All was good but a number of users (in the tens) complained that there was no way to select a default card so that they could make quick payments without having to manually choose a card each time.

Ok cool the product manage thought, release 2 will be a feature that allows all users to assign a default card for making payments and all users who have one card on file we will automatically make that card their default payment method. Boom, a few hundred thousand dollars later (these costs are the norm in large corporate enterprises) the product manager launched an update and boy was there backlash! Hundreds complained over the lack of choice they had over having a default, lots of payments from incorrect user cards were made, payments completion time actually increased because this new feature came out of nowhere causing users to be extra vigilant while navigating the payments process.

So what could this product manager have done differently. Firstly, they shouldn’t have responded to a small volume of qualitative feedback and acted so immediately on feedback that followed a major uplift — we see lots of feedback after any major release. However, let’ suppose this product manager had a good case to explore the ability to set a default card — maybe the first step would have been to simply launch a ‘use same card as last time’ button to gauge how many users actually found this efficiency useful. The product manager could have gauged appetite for the feature by doing this.

They could have simply launched the feature to a beta population of their most digital engaged users to harness validated learning and affirm their hypothesis (which they never defined) but I would have said would have been something like, ‘I believe by adding a default card option that speed of completion will shorten’. It would of also helped if they had launched with some clear metrics to measure the impact of their new feature and they shouldn’t have really just acted off of quantitative analytics from the get go….but I digress. Simply, do yourself a favour and think about what is the least you can launch to derive some validated learning to inform your next product decision.

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, I’ve had managers who have not used the products they own whatsoever and it’s like a kick to the teeth for the product 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 to 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 miss. 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 competitor is 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. However, we also want to make sure we’re still being copied because our competitors think we’re heading in the right direction. I remember a particular example of a role that I left as a result of a situation whereby we did the opposite of what our competitors did because the HIPPO’s (highest paid person’s opinion) overrode what we knew was the better way to proceed. At the start of the responsive/adaptive movement we were keen to begin developing for different popular breakpoints but the HIPPO wanted dedicated mobile sites so that they could wrap them up into hybrid applications (we wanted native applications).

Safe to say that all of our successful but at the time trailing competitors went in the direction we wanted to but our HIPPO refused too. This won’t always be the case. Some people will see something their competitors won’t and abstain or move early but if you blindly ignore what the masses are doing it’s likely that you’re missing something fundamental. Don’t take this is me saying ‘don’t innovate just do what everyone else is doing’, hell no — take risks and dream big but just use your competitors as a sanity check from time to time.

8. Fail to Challenge Assumptions/Consensus

My favourite manager was one who asked purposefully stupid questions because they knew they could exploit the ‘I’m new here so I can be ignorant’ freedom. It was their way of challenging assumptions without offending people by saying ‘hey, why the hell do you do things like this’ they would instead say ‘so what is your test driven development setup’ … oh you don’t have one.

This will also pay dividends in your design meetings, there’s a pyschology phenomenom 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’ fit 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 reason 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

Well ain’t that a no brainer — so many times I’ve seen people 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 harboring insight from their end users. Too many times I’ve also seen web analytics tagging crammed into the last sprint of development and ultimately suck and be completely useless when a product launches.

Perhaps more importantly is the notion of only having a feedback loop for launched products. 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 could go on and on about this one!

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 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 listen. 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 i.e. make the receipt of your checkout process PDF downloadable so they don’t have to waste ink…ten minute enhancement but you will reap the rewards with you human approach to responding to feedback.

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 in it 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 the boss look good. 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/boss/organisation’. 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.

Read the full post on the Product Manager Club site, and check out tons more articles on product management strategy.

Also, subscribe to the weekly newsletter!

Like what you read? Give Product Manager Club a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.