How I take an idea and turn it into a product
10 steps on how to tear an idea down to brass tacks, build it up, and ship it into the market.
A startup product manager’s role is to develop product strategy, research and define products, and coordinate the tactical execution of products from inception to go-to-market. Here’s the process I go through to take an idea to market.
There’s a lot of variation within each step. I’m not going to get into that, rather, I’m going to give you an overview of my process to help those with less experience better understand the day-to-day items.
How I go about it
At Teem we craft products to make working in an office easier for employees. In the example below when I say “space” I’m talking about spaces within an office — like a meeting room.
(1st) Understand and break down the idea:
Finding and using the right space should be frictionless.
This idea came from zach holmquist in one of our early product meetings. This idea is specific to our domain of workplace tools for employees. You’ll have completely different ideas but can break them down in a similar way to know what to ship. Let’s break this thought down into something specific.
Finding: Employees/users have to find a space. How do they do it now? Apply this workflow to an adjacent idea. What methods do we employ to find other things? How is finding a meeting room similar to finding your gate at an airport or the bar you’re meeting friends at?
Using: The user has a distinct purpose for finding the space. People use space differently, and different spaces are built for varying use. What patterns are there? Can we group these patterns into underlying structures or mental models to understand how our users think?
The right space: This is similar to the one above it (using). However it communicates that, at least in some instances, there can be “wrong” spaces.
Should: Should != Must. Should implies some level of acceptable imperfection in the process/experience.
Frictionless: What is the experience today? What causes friction? What friction can be eliminated?
(2nd) Review the user’s current experience from a high level.
Today most employees find a meeting room in three ways. First, they look around from their chair to see which rooms are open. Second, they compare room schedules in Outlook to see what’s not scheduled. Problem is — calendars are about 65% accurate. Finally, they walk around the office until they find an open room, often peeping into rooms to see if they’re open.
(3rd) Mash the current user experience with the idea.
What friction can be removed from that experience? Let’s focus on the user on the go, who walks around the office to find a room. To eliminate the aimless search, the user needs to know of an available room that fits their needs. Then they could walk directly to the right space and use it without the friction of checking other spaces.
Goal: user knows the right space, knows if it’s available to use, and knows how to get there — as fast and as effortless as possible.
You’ve now taken an idea, and created a product vision for an individual product or feature. To be successful at steps 2 & 3 you need to know your users extremely well. If you don’t — start interviewing them.
(4th) Ideate and collaborate
Ideation is fun because you get to come up with all sorts of ideas and iterate through them. I recommend looking to adjacent industries to find patterns and parallels that you can apply to your microcosm. Be sure to include a mix of disciplines in these sessions so you can benefit from a variety of perspectives. There are a ton of resources on how to do this, so I won’t go into detail. Once you have a solution thought up, that’s when the hard part starts.
(5th) Define the product and rally the troops
From here on is the brass tacks — the nitty gritty — the weeds; and it’s where many pm’s get overwhelmed and distracted if they’re not careful.
Start with product requirements and designs. Product requirements outline the problems and user stories you’ll be addressing. It should include functional behavior, clarification for edge cases, and any other requirements your engineering team needs. Your level of detail here depends on your engineering team — do what they need to be successful.
Then facilitate engineering discussions and get them excited about the impact of the product. You’ll have to understand how the engineering team is thinking about solving the problem. Engineering’s creativity will influence your product and design decisions.
On rallying the troops: whether they want something for a resume, or to feel gratified that they’ve done something worthwhile — people want to work on meaningful products. Rally them around the impact they can make.
(6th) Test and sell
Next, prototype, test, and iterate until you have something that users find intuitive and valuable. Testing and iterating not only improves your product, it builds credibility across your teams. Morgan Williams is my UX partner, and he’s extremely talented at this, which helps me a lot. The reason he’s so good is that he’s self aware about what he’s observing, and what he’s assuming. He also has practiced a lot at improving his craft. Invest your time into learning how to do this well.
In parallel with testing, you need to sell the idea, the strategy, and the impact this product is going to have. This communication should include the items important to your organization. Some rely heavily on quantitative analysis and others expect a report on how it will impact the company’s mission. Figure out what your company needs and deliver that.
(7th) Break down the work
Sit down with engineering and scope out the individual project milestones. Milestones break down into individual tickets/stories that a developer will build. In a startup, you likely have to do this in partnership with an engineering lead as you won’t have a project manager.
(8th) Coordinate cross team execution
There’s a lot that goes into coordinating cross team execution — but the biggest factor is your ability to communicate clearly and effectively. Effectively, meaning other people understand you. If they don’t — it’s your fault as the product manager, not theirs. You own this product, the communication, and the timelines.
There’s a lot that goes into coordinating cross team execution — but the biggest factor is your ability to communicate clearly and effectively.
(9th) Beta
Once you have a working product you will often need to beta test it. I’m still learning how to run efficient and effective beta programs. The best beta programs I’ve run so far have consistent and frequent communication with the testers, good data to see what’s going on with usage, and clearly defined learnings we can apply to the product.
(10th) — organize and execute on the Go-To-Market plan
Going to market is awesome. I’ve had the opportunity to do it a number of times now and each time I do it slightly different based on what I’ve learned along the way. The key is communication and knowing what resonates with your market. Hopefully, you have marketing and sales resources to help you with this. These discussions should start during step 5.
Finally — track and hold yourself accountable
Did you make the right decisions? Be honest, and ideally — use data to show an objective report on your product’s performance. Many startups don’t have reliable usage data. In that case, jump on sales and support calls. Find out who’s using it, and what their experience is. Derive data from these conversations and report on it.
On evolving communication
Throughout this entire process you’ll need to communicate to the company about your product (the decisions you’ve made, the status it’s in, etc.). Every startup is different, and every team is different. Learn how each team communicates and evolve your communication to fit their needs. Startups also change quickly — so learn to evolve rapidly.
So…what did we build?
We built an interface that showed a map or list of an office with rooms and other spaces colored green or red, denoting real-time availability. Companies hang it around the office on TVs and users simply have to walk by one to know the right space, know if its available to use, and know how to get there.
We called it Flightboard.
This job is the only job I know where you need to be both visionary and tactical on a frequent basis. Other teams rely on you to understand both the vision and today’s challenges they are facing. As a startup PM, I’ve failed many times and had to evolve quickly to keep up. What I’ve learned is that ultimately, product management leads an organization by serving every other team.
- dal
Thanks for reading! If you found my ramblings helpful go ahead and give it a few 👏 so others can find it.
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +383,380 people.
Subscribe to receive our top stories here.
