Time to read: 6 min
Here at Mindtribe, I regularly meet with teams excited to turn their fledgling product concept into a physical reality.
Teams come in all shapes and sizes—both startups and big companies, with varying levels of experience and states of clarity around their product concept. My job is to understand their vision and help them transform it into a successful product.
In this post, I’m going to walk you through the process we use at Mindtribe to define the most important product features in the early stages of development to create a Product Requirements Document (PRD), what we call the Product Nucleus.
Getting to the Feel Good Stage of Product Definition
One of the first questions I ask myself when meeting with a new team is whether they’re at the feel good stage of product definition.
If they can describe what their product is, who it’s for, and why they’re building it in a few sentences, and everyone in the room nods and understands, they’re at the feel good stage. It feels good that everyone in the room has a clear understanding of what’s being built and why.
This is a great milestone! They’ve successfully navigated the vast seas of user needs, product concepts, and business models, and refined all that ambiguity into a simple, clearly enunciated product concept everyone can rally around.
At this point, many teams start developing their product in earnest, and why not? Everyone’s clear about the product being built, so it’s a good time to get going already!
Right?
How Can Feeling Good About Your Product Concept Be…Bad?
The danger at the feel good stage of product definition is that despite individuals feeling good about their understanding of what’s being built and why, each person is actually imagining a slightly different embodiment of the product in their mind.
There are so many details to resolve between the feel good level of product definition and an actual product, that the product itself can vary a lot based on how those details are resolved.
For example, the design team might be imagining a user experience that prioritizes ease of use over all else, while the business team is counting on a certain set of features to capture the largest market, while the engineering team is managing technology risk to meet schedule. These inputs all point toward slightly different products, yet they all fit perfectly within the feel good product definition.
The product is being optimized for different things, yet nobody realizes it until there’s a prototype on the table and someone says that’s not what we wanted!
Valuing different aspects of the same product is expected (say, product cost versus materials, fit, and finish). In fact it provides the healthy tensions you need to be able to make the right product. The problem occurs, however, when these differing priorities reveal themselves after many weeks of development, when the cost of change is high. Prototypes have been built, sales promises have been made, and the organization is forming itself around a specific product launching on a specific date. Changing just about anything at this point induces pain, and the closer to launch, the more acute the pain.
Beyond Feeling Good: Establish Product Priorities
So how can you ensure the entire product development team envisions the same product before development begins?
Establish clear, user-based product priorities.
This means clearly defining the user needs the product addresses, prioritizing those needs, and aligning the entire product development team around them.
Voices representing the user, business, engineering, and design should all agree on the chosen user needs, in order of importance.
This is easier said than done and often triggers plenty of healthy discussion! But if you can pull it off, you have a huge advantage. You’ve reconciled subtle differences in product vision while the cost of change is very low (namely before you’ve built anything), and the engineering team has a roadmap of priorities so they can work towards validating the most important aspects of the product as soon as possible.
You’re positioned to make the right product for your users and business, as fast as possible.
The Product Nucleus
At Mindtribe, the tool we use to establish these product priorities is The Product Nucleus.
To create a Product Nucleus, you start by establishing the user needs your product should address, in order of importance. Prioritization is key—without it, there’s still room to feel good while each imagines the product in substantially different ways.
The product definition then becomes the minimal set of features required to meet each need and the engineering team starts developing the most important features first.
As an example, here’s a simplified version of the Product Nucleus from Adobe Ink, a pressure sensitive, cloud-enabled drawing stylus for Apple’s iPad:
User Need #1: Ability to Create Beautiful Lines on an iPad
- Feature 1: Capacitive stylus
- Feature 2: Palm rejection
- Feature 3: Pressure-sensitive
User Need #2: Designers are Proud to Use It
- Feature 4: Beautiful, fashionable industrial design
- Feature 5: Excellent feel in the hand
- Feature 6: Class-leading ease of use
User Need #3: Better UI Workflow Than Finger Alone
- Feature 7: Hardware inputs/interface element (single button, LED status light)
- Feature 8: Stylus-enabled UI elements (pen-tip menu)
By focusing our engineering team on the most important features first, we were able to build a pressure sensitive stylus with the envisioned look and feel that we could test with users in six weeks.
Artists told us the tip here was not small or precise enough to make beautiful lines—very good to know since everyone had agreed that this was the most important aspect of the product! We needed an active tip technology to achieve what users needed, but it would change our entire development approach for the product. By learning this two months into development, as opposed to six months or more, we maximized the amount of time we had for a Plan B! We were working toward the right product, as fast as possible.
As a bonus, a Product Nucleus simplifies defining your minimum viable product. Just draw a line representing the set of features you’ll ship in the first product as high up the list of user needs and features as possible. If development doesn’t go as planned, you can shift that line up or down to balance release date with features.
The Problem with Specifications
To avoid the risk of any degree of unclarity or miscommunication, many teams overcompensate by creating highly detailed specifications to describe exactly what’s being built up front.
Product specifications aren’t inherently bad, but they do have two major shortcomings that are often overlooked:
One is that specifications don’t indicate feature priority, or if they do, they don’t include more than two or three levels at most. Faced with detailed specifications, engineers have no way to know what’s most important to work on first. They might divide and conquer across all the features, leading to a large, painful integration far down the road, work on what seems most risky, or simply what’s familiar, fun, or challenging.
The second shortcoming of early specifications is teams will invest precious time detailing features that will inevitably change down the road.
The Product Nucleus, on the other hand, gives the engineering team a roadmap of the most important features and functionality to work on first, while not being so specific that time is wasted detailing aspects of the product that will most certainly change, be proven unimportant, or not needed for the first version of the product.
Where to Start
Next time you’re developing a product and feel good about what you’re making and why, see if you can go a step further and prioritize the user needs (and resulting features) your product addresses, in order of importance, and have your whole team agree on it.
It will most likely surface subtle (if not major) ways people on your team imagine the same product and help you reconcile those differences with the maximum amount of runway, and before changes become too painful or costly to make.
Taking the time to align your team around what’s most important in your product—and doing it as early as possible—will dramatically increase your confidence that you’re spending your time and resources to build the right product, faster.
