A Product Manager’s Worst Nightmare

By Daniel Elizalde
May 26, 2016

Imagine that the product you’ve been working on for months or years implodes on its first day of life—product management’s worst nightmare. Unfortunately, this story happens too often in the software world. Here’s what you can do to prevent it.

Rate

A failed launch is that terrible situation in which your product starts breaking or misbehaving as soon as it is launched into production. You and your team have spent the past few months planning and executing on the requirements, but the day you launch to production, something goes wrong.

Users can’t access the software. Errors appear all over the place. The site is non-responsive. And this is all happening while your marketing team is working at full steam letting the world know about your grand new product release. It is product management’s worst nightmare.

The good news: With strategy, planning, hard work and a bit of good luck, you can avoid these failed situations.

Define an MVP that Fits Realistically into Your Timeframe

In any product release, no matter how low or high the stakes, it is important to have a clear understanding of the requirements and to propose a MVP (minimum viable product) that is doable within that time frame. It’s better to release something that has limited functionality but is very stable than to release extra bells and whistles at the expense of reliability.

Remember that software is always a work in progress. The only certainty after a successful version 1.0 release party is that the following Monday, you’re back to work on version 1.1.

Be Realistic About Your Team’s Capabilities

As you create the product roadmap and pitch it to executives, it is important to be honest about the capabilities of your team. We often fall prey to the halo effect and believe that since we have a great team of back-end developers, they can tackle any other area, such as mobile, UI, etc. However, software disciplines are very specialized these days. For example, in SaaS software teams, it’s common to find specialists for services, database, networking, front end, security and mobile.

Make sure you work with engineering leaders to understand what it will take to build the product. If your product is complex, needs high availability or has tight deadlines, be realistic about whether your existing team is sufficient to meet those needs. You might need to change scope or convince the executive team to hire the resources you need. Otherwise, it’ll be almost impossible to deliver on the product promise you are making.

Don’t Forget to Include a Project Manager

Agile zealots might not agree with the idea of having a project manager. After all, the product owner should be able to handle it all, right? I don’t think so. This approach might work for small products with a handful of developers, but when the scope grows, this model doesn’t hold.

Complex products will have multiple teams working on related items, and there need to be people dedicated to making sure everything fits together. Scrum of scrums can help, but in my experience it is better to have people dedicated to tracking progress and timelines and making sure everything is advancing in the right way. This need is accentuated if your product includes both hardware and software.

A strong project manager can own the day-to-day operations, keep track of the goals vs. the schedule, and keep everybody on the same page: vendors, engineering and other departments. This person can be the central point of communication for reporting status and risks.

A note of caution: The fact that product managers often have a project background doesn’t mean we should take on both roles at the same time. The more we can offload those responsibilities to a dedicated project manager, the more risk we mitigate and the more time we’ll have to focus on key product needs. If you find yourself doing more project than product management, you are probably not adding all the value you could be.

Agile Development Can Reduce Risk

Agile provides a framework for minimizing risk by implementing iterations that produce working software. It is not a silver bullet, but it can help a lot. It provides us with a framework for continuous improvement, one sprint at a time.

Each iteration is self-contained, meaning that it includes design, development and testing. Therefore, the code on every single iteration is tested to ensure it meets the desired levels of quality.

As part of the testing strategy, the QA team should develop unit tests, perform regression testing and build a comprehensive automated framework to validate all the use cases defined by product management. There will always be some manual testing on every iteration, but the better the automated coverage, the better the chances of success.

Now, making sure the development team implements the right delivery processes is not the responsibility of the product team. It is the responsibility of the delivery team, and their engineering leaders, to make sure that their execution process yields good results. But in many companies, especially at small startups, these processes are often not in place.

Since the product launch is your responsibility, do some investigation to ensure all the right processes are in place. If they are not, then it is okay to start conversations with development leaders and begin shepherding the creation of those processes. Otherwise, your chances of success will be greatly diminished.

Plan for Performance and Stress Testing

Product management must understand the impact to customers when their product is down. For example, if my system fails, will businesses cease to operate? Will electricity go down? Will people’s lives be in danger? The bigger the impact, the more you have to plan for performance and stress testing.

You also need to understand your audience and the overall usage of your product. This understanding should be part of the product requirements. You should be able to answer questions like:

  • Will we have 100 or 100,000 concurrent users?
  • Which times of day are more likely to have peak usage?
  • What redundancy and elasticity specifications does the product need in order to meet demand at peak times?

Understanding the constraints is the first step. The next one is to come up with a plan to test them and ensure you’ll be ready to handle them when they occur. Make sure to have some projections on how your adoption will grow and how your infrastructure needs to scale in order to meet that demand. Chances are you’ll be way off, but you need to start somewhere.

Page 1 / 2

About the Authors

  • Daniel Elizalde is a seasoned technology product leader, with 17 years of experience developing high-tech products for startups and global companies alike. He is also the author of the popular blog TechProductManagement.com, a real-world guide to IoT product management. Daniel is head of product management for Stem, Inc., which leverages the power of the Internet of Things to develop energy-storage solutions for the Smart Grid. Follow Daniel on Twitter at @delizalde.



Post a Comment

Comment

Allowed HTML: <b>, <i>, <u>

0 Comments