Making It Right: Product Management For A Startup World

by Rian Van Der Merwe

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.

The product manager’s mission is to achieve business success by meeting user needs through the continuous planning and execution of digital product solutions.

These have their feet firmly planted in the mud of the practical world, and yet stretch far enough to stick their head in the clouds when they need to. Furthermore, they simultaneously span all of the space in between.

What does “the endless immensity of the sea” mean in your context? Instead of telling people to build a bunch of features, how can you inspire them to think about how the product will help users accomplish their goals? That’s how you’ll be able to unite teams around a common vision.

This combination of being qualified as well as able to keep learning indicates that product managers need to be insatiably curious in everything they do. Why? Cap Watkins puts it really well17:

I urge each and every one of you to seek out projects that leave the world a better place than you found it. We used to design ways to get to the moon; now we design ways to never have to get out of bed. You have the power to change that.

Instead of asking what problem you should solve, ask what problem you wish someone else would solve for you.

•User needs. The PM must have a good understanding of the market, the company’s customers (existing and potential), and their behaviors and attitudes. PMs should never be caught off guard by questions about the product’s target audience. We’ll look at different sources of user input, including market research, user experience research, site analytics, and customer support.

•Business needs. The “putting users first” mantra too often neglects the fact that a product exists to make money. Having revenue goals is not an excuse for bad design, though, so we’ll look at the difference between bad revenue streams and good revenue streams.

Minimum Desirable Product is the simplest experience necessary to prove out a high-value, satisfying product experience for users.

This might be controversial, but I believe that product roadmaps shouldn’t have dates associated with projects, only priorities. That’s where my views start to converge with Jason’s general principle in his post — work on the most important thing until it’s done, and then move on to the next thing, and the next.

Eighty percent of software lifecycle costs occur after the product is released, in the maintenance phase. Of that work, 80% is due to unmet or unseen user requirements and only 20% is due to bugs or reliability problems.

63% of software projects exceed their budget estimates, with the top four reasons all relating to product usability: frequent requests for changes by users, overlooked tasks, users’ lack of understanding of their own requirements, and insufficient user analysis communication and understanding.

[F]ailing to write a spec is the single biggest unnecessary risk you take in a software project. It’s as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to “wing it.” Programmers and software engineers who dive into code without writing a spec tend to think they’re cool gunslingers, shooting from the hip. They’re not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.

From the prioritized backlog, I’ve still experienced that the most effective way to keep the design team involved throughout the delivery process is to make sure design and prototype testing happen a sprint or two before each of the delivery steps. In this way the generic model for product management I shared in this book can still be applied effectively to agile development.

The product manager’s mission is to achieve business success by meeting user needs through the continuous planning and execution of digital product solutions.

•The product What does the company sell? What does the product do? How does it work? What is the value proposition? What problems does it solve for customers? What features does it have? What kind of bugs does it have? What are the main usability issues?

•The market Who currently uses the product? What are they like? What are their characteristics? What do they like and not like about the product? Who is the target market? Are there personas for each different type of person in the target market? What are macro- and micro-market needs addressed by the product? Who are the competitors?

There are thousands of ways to make a living. But we, the product managers, choose to spend our time dreaming up products and getting them out into the world. That is an incredible privilege, and an opportunity I wouldn’t trade for anything. We get to work on understanding people, and finding out how technology can improve their lives. Yes, it’s stressful, but it is so, so worth it. Let’s go make the best products we can possibly make, together.