How to Begin

Are you building a new product? Here’s three quick steps to make sure you build the right foundation for your product and company.

Over the past year I’ve spent time working with a number of young startups. Each company is building software and they’re at the point where they’ve launched something small to test product/market fit. I was brought in to help with UI/UX design and defining the product roadmap.

During my time working with each company I noticed that each of them struggled with the same core issue: they’ve launched an MVP and have no clue where to go next.

The solution seems dead simple… listen to your users and you’ll figure it out! Unfortunately, it’s not that easy. Most startups launch to such a small group of users that it’s hard to measure what’s working and what’s not and that can lead companies down the wrong, deadly path… but that’s a post for another day.

Working through the post-MVP product issue with each company, a much larger and less obvious problem came to light: the companies had launched an MVP without understanding what hypothesis they were trying to prove and if successful how they were going to evolve their product.

As a product builder my self, I’ve fallen into this trap dozens of times. Most startups are so eager to get something live they skip the necessary steps to building the right foundation for their product and company. To combat this I’ve outlined three dead simple steps that I bring product teams through to solve this issue. Let’s get started!

1) Define your product’s goal

Every new product is trying to solve a problem. I find it useful to document what that problem is and have it visible for the entire team at all times. This not only helps rally the team around a common cause, it provides your product team with a baseline goal that they can compare their thinking to. For your MVP, v2, v3 the product should always be working towards that goal.

Where I’ve seen this cause issues for small teams is understanding the different between the product’s goal (what it will do for the user) and the product feature list (what things will be in the product). A simple trick that I suggest teams apply when thinking about their product is to frame their language around what their product will do for the user versus what their product will be able to do.

Finally, having a product goal will help your team to continue to move forward even if you don’t have a ton of useful (and measurable) user feedback.

2) Map it out

Continuing with the theme of step one, once you have a goal you need to create a map of how you’re going to get there. I create three different types of maps:

  1. Low Detail Map: Map out every single screen in your product with a simple title. This map will help you understand how large your platform is and give your team a clear understanding of how it works when testing. For each map I like to use Google Drawings.
  2. Medium Detail Map: Returning to your low detail map, begin to fill in what information needs to be on each page. For example, if you have a home page screen, create a bulleted list of all the information that needs to be presented on that page. At this point you are not designing the UI, you’re simply listing out the information that needs to be represented. This map will help you understand how intricate your system is and where the user may get lost when using your product.
  3. High Detail Map: Now that you have a full product map with screen details it’s time to start wire framing. However, The high detail map wireframes should still be extremely lightweight. Stick to blocking out the UI with lines and text. The goal is to organize the information that needs to be presented not designing it.

3) Circle your MVP, v2 and v3

Now that you have a clear understanding of your products goal and a map of your system you can now define what your MVP and subsequent releases are going to be. I always suggest printing out the high detail screen map for the team to draw on for this step. To define your different releases, take a Sharpie to your map and circle the parts of your platform that you believe are the smallest versions that deliver on your product’s goal. Circle your different releases in different colors to more clearly define how the product will grow over the next X months. You‘ll return to your product outlines and adjust them as user feedback is collected.

After completing each of these steps your team will have product documentation that can keep everyone (internally and externally) on the same page as you progress through each release. You’ll be able to clearly depict how your product is going to evolve from MVP to future versions and how each release aligns to your products goal.

I’d love to hear from other teams and builders on how you approach creating your ideas. Comment below or connect with me at @gmoore131