4 Product Management Hacks to get the Most out of Failure [Mind the Product]

Failing is an eventuality in software development. Not only do we fail, we are encouraged to fail iteratively. Let’s do it over and over again!

And yet, the job of the product manager comes with a level of accountability and scrutiny that is unique. Product managers are asked to look after all facets of a product’s development, from conception to launch. From software design to user experience. From consumer needs to integration points. Jobs to be done, design-led thinking, microservices, object orientation, service orientation, user stories, product-market fit, launch strategy, data models, customer segmentation, framework after framework, after framework. A working knowledge of just some of this is enough to make anyone’s head spin, let alone keep it all in check in order to deliver successful products.

After all, a large portion of the tech industry is in business precisely because they know we will fail, and advancements in software development increasingly take the pain out of failure. Cloud computing enables elasticity in anything from load balancing to server use, introducing the ability to take human decision out of scaling. Fears of excess payment have been reduced by pay-as-you-go models. Versioning allows us slowly to phase our approach and test new features. Disaster recovery and failover assure us that we will be kept safe despite colossal accidents.

More and more the technology community likens failing to falling down on a trampoline and jumping right back up. We no longer need to anticipate every customer need, get the journey perfect the first time, or plan for unexpected loads – Amazon, Microsoft, and Google will forgive us for planning poorly (at a small price of course).

The industry is moving at an unprecedented pace because it’s so easy to get up again after a failure. Deploying and launching is easier than ever before, so we are encouraged to just get to market. Just ship. Often we find ourselves asked to do too many things at once without doing any one thing emphatically well.

Failing has become the norm, imitation too easy, and costs are getting lower every day. Despite all of this good news, the product manager’s job seems to have become more complicated. If imitation is too easy, then proving competitive advantage is difficult. And if costs are becoming negligible, we have so many options that setting boundaries is hard. It’s getting harder to maintain competitive advantage and be sure we’re making the right decisions.

So how can we make the right decisions in a sea of options and competing products? While I’ve always found it difficult fully to get a grasp on what all my options are, I’ve found that the best way to inform my decision-making process is to roll my sleeves up and unpick each option. The daunting task of really understanding how everything works has come in handy when selecting vendors, choosing which features to prioritise, and building products that will scale – constantly fighting the urge to come up with high-level solutions and roadmaps first. Start from the bottom, block by block. Here are some of the hacks and tools I’ve found that have made my decision making easier, and which have helped to make my failures a positive learning experience.

1. Milk the System

If there are a variety of tools available and switching is easy, find the one that works best for you. This sounds trivial, but take advantage of the free trials and free demos. Get your hands dirty! Play around even as a product manager to understand exactly what set of tools you’re getting. Example: sign up for an AWS, GCP, Heroku account. They’re all free to get started, and you can get a great idea of the suite of products they offer and which scaling options work best for you. And you’re allowed to ask for freebies. Don’t hesitate to ask. If there’s a vendor whose API you’re looking for, be empowered to ask for a test API. The most they’ll say is no.

On one of my projects, my team needed to spin up a static website to publicize our product quickly. We were limited, however, by our client’s governance processes and getting access to their enterprise AWS account. After playing around with AWS myself, I realized we could just as easily host our static website through Dropbox, since the underlying technology is the same. I knew it would scale well – if only to accomplish the singular goal of redirecting users to our core product. Not only did this solve an immediate short-term problem, it was the simpler, faster approach that let us concentrate on the larger product hypotheses we wanted to test with our customers.

2. Join Forces

Really think about whether building it yourself is the answer. In an open source world, the chances are that someone’s already built it. You might think what you’re after is easy enough to build yourself, and that’s your call. But part of your expertise comes from understanding how long and how much it would take to build it yourself and comparing that against the cost of purchasing. It might even be free! Do the research.

3. Build it Yourself

This sounds contrary to number two, I know. Sometimes there will be products that do what you need them to do, but not always in the way your team or your product needs them to be done. Try your best to make an accurate assessment of whether your team can build this, because if they can, you’ll have your own proprietary technology completely fit for purpose. And if they can’t, even better. You’ll have learned a variety of lessons about your dataset that you will not have foreseen before. Time constraints and resourcing constraints will dictate whether you can afford to go with number two or number three.

4. Deploy as Frequently as Possible

The deployment pipeline often isn’t in the hands of the product manager, but when you can control how often your team ships, do so. Each release will teach you a variety of lessons, specifically about your dependencies and data points. You will not be able to anticipate each edge case and linkage until you’re actually experiencing it. The more you release, the more things will break. Fix them and move on. If you haven’t guessed already, that’s the theme of this article! The urgency here isn’t in releasing or shipping fast, the urgency is in learning fast. And a wise someone somewhere once said, “you learn the most from your mistakes”.

As product managers, our jobs are not to prevent or reduce failure, rather to overcome failure after failure while getting the best out of our products and teams. So we should look beyond “getting everything right” the first time, or even the second time.  Failures in themselves are elastic, and the important lesson to be learned from each failure is what each one taught us about our customers’ needs and preferences, our teams’ ways of working, the data we have, and the journeys that will deliver the most value.

The post 4 Product Management Hacks to get the Most out of Failure appeared first on Mind the Product.

Source: Mind the Product http://www.mindtheproduct.com/2018/07/4-product-management-hacks-to-get-the-most-out-of-failure/