You have been tasked with building a new product. Now what? Don’t just jump to solution mode, you might miss out on some great ideas. One of the most important pieces of advice: Collaborate! Involve your customers, your stakeholders and your team, they all have unique knowledge that can help you with every step you need to take to build an amazing new product or optimize an existing one.
A new product doesn’t have to be intimidating: 6 steps for a smooth start
There are several scenarios when you’re assigned to build a new product, two of the more common ones:
- There’s a strategic goal that your company wants to reach based on overarching business goals. This means you can build any product to reach it. Personally, I like this one more, more freedom to explore and experiment.
- Even more common: Someone had an idea. Someone can be from the marketing or sales team, a customer success agent or one of your team members. A lot of the time, these ideas are based on some rough market research, conversations with customers, competitors’ products, emerging technologies or really just a hunch.
No matter the situation, you need to get into the details: What specifically do users need so that they’ll try your product and then love it so much they stay? To answer this question, we need to loop through these steps: Discover, Ideate, Prototype and Validate, Build and Ship.
Does that sound familiar? It is based on design thinking, lean and agile methodologies. I’ve found that quite often they end up being separated from each other, this leads to a disconnect. Design uses design thinking, development delivers based on agile methods and the business side of things is supposed to be lean. Well, since product managers supposedly sit in the middle of all of those disciplines, we should facilitate a conversation and use the best of all worlds.
This will give you a basic overview of methodologies the steps are based on and how they work together. If you are familiar with them, feel free to skip ahead.
The methodology itself is not a new concept, it has been around in manufacturing. It champions the notion of continuous improvement.
You start with an idea, you build it (code), this lets you measure data from which you learn and inform another iteration or a new idea and then you go through the cycle again. All while trying to increase speed through the circle.
This approach in itself does not necessarily address how to build or how to ideate.
The first step of the lean cycle are ideas. I have also seen “Identify” and “Plan” there. Either way, this screams design thinking which is a method for creative problem-solving in 5 stages/phases/steps:
Design Thinking is a systematic, human-centered approach to solving complex problems within all aspects of life. The approach goes far beyond traditional concerns such as shape and layout. ~ HPI Academy
I will connect these stages to my product building steps below.
Agile thinking is the base for fast delivery, it leaves out the idea part and helps teams to organize the way they work together.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These principles were part of the Agile Manifesto which then inspired more practical frameworks like Scrum and Kanban. Sometimes you find that any mix of these two is referred to as Scrumban. The rule of thumb to answer when to use which one is, if the team and/or product is mature use Kanban, if either is still new, use Scrum. At the end of the day, it depends on the team’s preference.
Find out more about the agile way of thinking and Scrum specifically in one of my favourite books “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland.
One of the greatest resources on connecting all the methodologies is the book “Lean UX” by Jeff Gothelf and Josh Seiden. If you need a faster read, I can recommend “Lean vs. Agile vs. Design Thinking” by Jeff Gothelf.
[Most of the following part has been published before as part of Ask Women in Product: What structure or process do you use to understand a new product?]
In the Discovery phase, your goal is to make sure there’s a user need, that there’s an adequately-sized market with that need, and that you know the source of the user’s problem. That is the way to find a valuable solution.
So how do you actually find out what users need? You ask them!
There are two different kinds of research, exploratory or generative research and validating or evaluative research. While the latter tries to validate an idea with users the former is a way to find out what users actually need.
To find opportunities for solutions or innovations, consider using so-called generative user research. This method helps you define the problem you’d like to design a solution for. It is also referred to as exploratory research since you explore your problem space.
When conducting generative research, the most important thing to do is to keep an open mind: you don’t actually know what problem you are trying to solve yet.
Let’s say you’re looking to offer a meal product. Examples of methods you can use for exploratory research include:
- User Interviews. In my experience, the best starting point is qualitative research. This method gives you an understanding of a user’s underlying reasons, opinions, and motivations. Conduct some interviews. If you have a target market identified, look for interviewees there. If you’re not sure yet, make an educated guess. It’s more important to get started than to be right; your target group will become more clear through the interviews.
- Personas. A persona is a fictional character created to represent a user type. Here’s a simple example: Karen, who is in her mid-30s, has two children and lives in suburbia. Her older son plays soccer. Her youngest child is under the age of five. She hires a babysitter to keep an eye on her two children every Friday, so she and her husband can enjoy a weekly date night.
- Jobs-To-Be-Done. The Jobs To Be Done (JTBD) framework is a theory that is based on the notion that people buy products and services to get a “job” done.
Personally, I prefer the JTBD Framework over Personas. The reason is simple: You focus on the actual user needs in context and not on demographics. For example, your persona, Karen, will answer questions about her meal choices for dinner differently depending on her schedule that day. Did her older son’s soccer practice end late and she now needs a fast dinner? Then she might prefer a pizza. But her answer might be steak when she’s out with her husband on date night.
Remember, it’s not the customer’s job to solve their own problems. It’s your job to ask the right questions.
The last step is to frame your problem. Not for murder, silly! But make sure that you have a clear problem statement and you are aligned on which problem to solve before you jump into the next phase.
Alignment can only happen if you know what your customers want as well as your business stakeholders. I have found running The Lightning Decision Jam by AJ&Smart works wonders. It’s a short workshop format that takes roughly 90 minutes. It helps with alignment, but also collaboration, that’s why I consider it My Secret Super Power.
For more insights on problem framing and how to run workshops or exercises, I can recommend reading Framing Problems by Jay Melone, A simplified approach to Design Sprint problem framing. by Robert Skrobe and How to run a mini problem framing workshop? by Dana Vetan.
These 7 Product Prioritization Frameworks for Product Managers can also be very helpful when deciding which problem to focus on.
Once you understand the problem, it’s time to come up with a solution that you can then experiment with, test and validate, or change.
If you haven’t heard of it, a Design Sprint is a workshop framework that leads you through a proven sequence of steps that help you frame your challenge, gather information, get inspiration, come up with ideas, decide on one to pursue, prototype, and validate through user testing.
The sprint team is made up of people in different roles depending on the product and the problem that has been framed earlier. Participants typically include product managers, marketing managers, user researchers, designers, developers, and other stakeholders. Having such a diverse team fosters collaboration and creativity.
Remember Ocean’s Eleven?
A sprint resembles this perfectly orchestrated heist. You and your team put your talent, time, and energy to their best use, taking on an overwhelming challenge and using your wits (and a little trickery) to overcome every obstacle that crosses your path.
Here are a couple of methods and tips I’ve learned through Design Sprints:
- Remix + Improve. You do not need to reinvent the wheel. Get some inspiration from your favourite apps, websites, and products, then use them as inspiration. They do not necessarily have to be from your industry either; in fact, products and services from other industries might give you great new ideas.
- Pen + Paper. They may be “low-tech” but they’re also the least daunting way to get started. Since it’s only scribbling, people tend to be bolder and dare to come up with “crazy” ideas leading to actually feasible and innovative new products or features.
- Note + Vote. Brainstorming doesn’t work. Ever. Period. Don’t worry, you can avoid groupthink and biases by letting people come up with ideas on their own and then deciding which ones to use together. Write down ideas on sticky notes and then let everyone vote with sticky dots.
Prototyping and Validation
Now that you have a solution, you validate it through so-called evaluative user research. This type of research evaluates an existing design such as a prototype or a finished product in an A/B test, for example.
Now you want to validate your idea with real people in user tests and through interviews. Evaluative research can also be used very successfully outside of Design Sprints.
Evaluative research is assessing a specific problem to ensure usability and ground it in the wants, needs, and desires of real people.
You do not need to prototype the actual product during a design sprint; you only need a really good facade. For a physical product, your facade could be a landing page. For an app, you can stitch together a seemingly real and clickable app dummy. You can also have a human do the actual work when testing a chatbot. Or create a sales deck for a new business model. The possibilities are endless, for some inspiration I love reading Sprint Stories.
Building and Shipping
Let’s say you’ve created a successful prototype after another round of tweaks. What now?
You need to build the smallest set of features that make your product functional, launch it, and learn from it — that’s your Minimum Viable Product (MVP) or Minimum Learnable Product as Anaid Chacón, PM at Dropbox, put it in one of my favourite podcasts Product to Product — Debunking the “V” in MVP.
Your prototype usually has more capabilities than you need in your very first release, so how do you prioritize what exactly to build? I have found it useful to divide your features into three categories: Signature, Core and Other. This classification activity is part of the Product Definition Canvas created by TWG.
- Signature Feature. What’s the secret sauce to your product? Which feature would you like people to remember? This feature will most likely be your differentiator. Netflix’s “Browse” screen is an example.
- Core Feature. These are features that you need to make your app functional and fulfil basic user needs. Examples would be a login screen or settings pages.
- Other. As the name suggests, it’s all features that are not Signature or Core.
When building an MVP, you focus on the Signature and Core features and drop anything that is an “Other”.
Once your MVP is defined, you build it and then ship it. It really depends on your solution and features what building means. If you are creating an app, then you’ll need developers to code the signature and core features. Once your app has been thoroughly tested by QA, you can release it in an app store to ship it.
In some situations, it might make sense to declare your build as a beta and not release it to the general public. Whether it’s a private beta or a public release, the best thing about a shipped product is that you get to collect real user data and learn from it. Based on your findings, you can prioritize your next initiatives.
Congratulations! You have completed your first iteration. Don’t forget to capture your learnings along the way as you work through each iteration, looping through these steps: Discover, Ideate, Prototype, Validate, Build and Ship.