Building Products is More Than Just Features

Building products is more than just features. In this article, I share some of my learnings and experiences building products.

First, here’s a quick definition of what a product roadmap is so we’re all aligned. A product roadmap is a shared source of truth that outlines the vision, direction, and progress of a product over time. It’s a plan of action that aligns the organization around short and long-term goals for the product, and how they will be achieved.

Before we jump in, let me introduce myself, my name is Jonathan Poor and I’m a Product Manager with experience in Strategy and Innovation consulting for the past 5 years.

I have launched three client-facing products at Quesnay and Tunity. Over my career, I have drafted multiple product roadmaps, designed wireframes, and led customer interviews.

Starting your product career

Picture this situation: it’s your first day on the job (woo!). Your boss approaches you mid-day to start working on your first product roadmap. Excited and full of enthusiasm, you dive right in. However, where should you start?

Your boss gives you a list of features the team and upper management want to develop ASAP. Logically should these come first? After digging in, you discover the feature list includes ad-hoc requests from various managers in sales and customer success.

You realize no one talked to the users to understand their needs, what problems they are looking to solve with your product, or how these features align with your company’s overall strategy.

A situation like this smells like a recipe for disaster to me. If you decide to execute the current roadmap, you’ll probably find yourself reacting to requests. Which is different from what your role as a Product Manager is. As a Product Manager, you need to understand the user’s needs and together with the team to build solutions that solve their problems, create value for them, and drive business value.

Building products is more than just features

So what should you do? How can you create a solution that is aligned with your strategy and solves real problems your users are experiencing?

Here is a list of recommendations based on my experience.

Strategy first

The first thing you need to do is align the product with your company’s overall strategy and mission. At Quesnay, we wanted to help different participants of our innovation competitions connect post-competition. We aligned on this strategy because it fits our company’s mission of connecting startup founders with corporate executives and VCs for investment, proof of concept, and partnership opportunities. With this understanding, we were ready for the next step. But don’t forget – talk with all relevant internal stakeholders to understand if they are aligned with the strategy before moving forward!

Define your users and the job they want to get done

You’ll need to understand who will use your product and why they need it. Luckily for us, we already knew who our users were. Using this information we knew that post-competition our users were interested in keeping in touch and interacting with others before the next competition. We, therefore, needed to discover various ways how to help them do this.

Talk to your potential users

Now you have an understanding of who your users are and have an understanding of the job they want to get done. Let’s not assume anything. It is important to talk with the users to understand how you can help achieve their jobs to be done.

Use user interviews to understand how your users currently get this job done and why it isn’t working for them. Notice at this time, you should not have written one line of code. Nor any features are committed. We are still in the discovery process and are trying to lock-in on the problem we want to solve.

Another benefit of talking with potential users at this stage is to acquire a curated group willing to help with prototype testing once you are ready. My suggestion is to aim for 5 user interviews per user profile. This number will allow you to start seeing patterns and move quickly. More than 5 is okay, but the ROI on time invested is diminishing from that point forward.

Wireframes and mockups

Using the information you collected you now have some pretty solid data to start thinking about building your product. Based on the user interviews and the data you collected, you can prioritize features and create mockups.

For each feature: create a user-journey, a storyboard, and a wireframe. Using your wireframes, you can build a fully functioning mockup using Sketch and InVision. If you don’t have access to these tools, Keynote is a quick and dirty way to build a very reliable mockup. Note: Some companies may have a dedicated designer (or team) to create your wireframes.

Test, iterate, build and launch

With the mockups created, set up additional user interviews to see if the mockup you’ve built functions properly and if it solves the problem you identified. This gives you an opportunity to let early adopters access and you gain vital information around the user experience.

If you need additional users, feel free to contact people from your target audience and include them. Again the magic number of user tests in my opinion is 5, so conduct 5 tests, analyze the data, make changes, and test again as necessary. Once you feel comfortable with your mockup, it is time to build your product.

Continue iterating

After you build and launch your product, you should continue talking with your customers, testing, and iterating. By doing this, you can continuously update your roadmap with impactful features that align with your strategy and answer your users’ unmet needs. It is recommended to have a cadence of check-ins with all relevant stakeholders to keep them informed and establish clear communication channels.

That’s it from me for now, but if you would like to connect to talk about product strategy and creating impactful product roadmaps shoot me a message. Best of luck on your Product Management journey.

Leave a Reply

Your email address will not be published. Required fields are marked *