If there was no competition in entrepreneurship, no one would be incentivized to innovate and create better products! It’s important to have a handle on your potential competitors as you develop your product roadmap. In this section, you’ll learn how to research the competitive landscape and structure your roadmap to navigate the marketplace.

Why You Need to Do a Competitive Analysis Before Building Your Startup

When it comes to building a startup and the entrepreneurial journey that accompanies it, competitive analysis is about the least exciting thing you’ll ever do–but it’s also the most important.

Spending years and millions of dollars of someone else’s money without doing comprehensive market research beforehand automatically lowers your chances of success. The issue is that most entrepreneurs are super passionate about their product and want to hit the ground running. The last thing they want to do is spend a month researching to create a market landscape.

That is a huge mistake. Here are some reasons you are going to want to do that research before starting your entrepreneurial journey:

Investors are going to ask you about it

Don’t forget for one second how important competitive analysis is for you–investors are going to ask you who your competitors are. Do it for them if nothing else.

The worst thing you can say to an investor is that you have no competitors. If you say that, there are only two options: either you didn’t do sufficient research or you’re right, and there is no one out there trying to solve the problem you’re solving. In other words, there is no demand for your product. Both of these aren’t situations you want to find yourself in.

It will help you decide on the next steps

One of the most crucial personality traits of a successful entrepreneur is flexibility or the ability to pivot when necessary. By creating a competitive landscape, you are able to make a more informed decision of whether to take a different direction or to continue moving forward with your current product.  

There is nothing as powerful as a visual representation of your market. When you have that graphic in front of your eyes, there is no lying to yourself about your chances of standing out. The landscape speaks for itself.

You can establish your differentiators

By seeing what other players in your space are doing, you are now able to determine what your differentiating factor should be. What are others doing? Who is succeeding? Who is failing? Why? All these questions are crucial, and competitive analysis will help you answer them.

You’ll learn from the mistakes of others

Building a startup requires a balance of so many things. For example, looking at your competitors in order to copy them or see how they’re doing things is not recommended. Too many entrepreneurs assume the other CEO knows what they’re doing when in reality, they’re in the same boat as you.

On the other hand, not looking around you to see what lessons you can learn from others is crazy. It’s that balance that needs to be struck.

By making a comprehensive market landscape, you can see who is doing what in your space and learn from others’ mistakes. If you have an idea for a startup, that’s great, but before you execute on your idea, take a breather for a month and do research to build that landscape of the field you’re going to spend the next decade playing in.

(Content credit: Inc.)

How to create a product roadmap: step-by-step guide and free template for founders

This section was originally written by Laura Bosco for Krit.

So you have an idea…

You think it’s a good one and you’ve stockpiled 100 features that will make it the most valuable app on the market. #genius. The team builds everything: “no killer feature left behind!”

You launch with a beautiful marketing site, pithy message, and all those killer features tuned and ready for your hundreds of devotees.

Except the devotees don’t show up. The features don’t get used. And the pithy message doesn’t look so pithy anymore.

There’s a better way.

And it centers on defining your Minimum Loveable Product (MLP) and utilizing a powerful tool called a product roadmap.

What is a product roadmap anyhow?

A product roadmap organizes important product information in one place for key people. Atlassian describes it as “a shared source of truth” for project members and that’s a pretty good summary. But if you’ve never seen or created one, it’s also hard to visualize.

Since creating a product is a massive adventure, let’s define a product roadmap in terms of a smaller adventure. I live in Chattanooga, TN, and one of my bucket-list items is to drive up the West coast with my husband. That’s my adventure goal—see the West Coast.            

‍My vision is us in a jeep wrangler, 70-degree weather, the ocean on our left, and a salty, sunny breeze in our faces. If you pictured this at sunset you’re tracking with me.

Now to get from TN to my sunset drive, I need a strategy and a roadmap. For strategy, let’s say I want a cost-effective route that maximizes our opportunities for good hikes and stellar campsites.

Alternate strategies could be visiting as many vineyards as possible or an extravagant pre-kid vacation touring all the nicest hotels. But I dig the hikes and campsites trajectory; it fits our values.

So we have a goal, vision, and strategy. Now here’s where a roadmap is essential and a lot of fun—especially if you have organizational tendencies like me. The roadmap illustrates what concrete steps we need to take to get from Chattanooga to sunny and 70. What driving route will we take? Will we fly or drive out there?  

The roadmap outlines these specifics so my husband and I are on the same page about what we’re doing and how we’re doing it. It helps us identify and follow a clear path to our goal.

A product roadmap does the exact same things for your startup; it outlines how to meet your goal, carry out your strategy, and actually achieve your vision.

Why a roadmap? (Winging it is a lousy option)

For a startup of any size, a good roadmap will do the following:

• Outline what you’re doing
• Relate the what to the why
• Clarify your priorities
• Focus on key steps and features
• Enable good product decisions

You could wing it instead, but that’s a pretty lousy option. Take my West Coast example. Here’s what would probably happen without a roadmap:

• My husband and I forget to book flights until they’re super expensive. (What needs to happen isn’t clear.)
• We have frequent arguments about whether we’ll stay in cities or national parks, go for a week or a month, see mountains or coast. (We don’t have defined direction or priorities.)
• In the meantime, we book our calendar full of concerts, family trips, and weekend getaways. (Our time and budget isn’t focused on the goal.)

Meaning we never get to the West Coast at all. Or if we do, we have a PB&Js, a rental van that smells like mold, and enough tension to cloud the views—not at all the vision I imagined.

In startups, the parallel scenario looks like chasing every shiny idea or feature (unfocused), spreading budget out in confusing or frivolous directions (mismatched priorities), and working on whatever seems fun at the moment (unclear steps). All of which will lead you someplace you don’t want to be.

Roadmaps pave the way to a better outcome.

What should a product roadmap include?

Your roadmap won’t look much like my map of the US. Rather, it’ll be in a document or tool, like Airtable, Google Sheets, or Trello. And it’ll have more words than tent icons. (Though there’s no rule against emojis. 😁)

Your product roadmap should include:

• 3-6 months of work
• A prioritized list of features
• Enough detail to be useful

It should not include:

• Every idea that’s ever popped into your head
• Stuff you may do 2 years from now
• Specific dates
• 20 pages of notes and timelines

Remember, a good product roadmap has just the right amount of detail. A 10 tab spreadsheet with loads of notes and deadlines is something no one wants to open. It’s takes too long to digest. But a roadmap with too little detail is equally useless. Why reference it at all?

We’re going to get into the gritty specifics of building out your roadmap, but first we need to cover some super important context. Otherwise, creating your roadmap is going to be more difficult than getting to California on a motorized scooter.

Pre-roadmap essentials: who, why, and what

Before you build out a product roadmap, you need to start with some fundamental questions. Questions like, “who is this for?” and “what value does it deliver?”

For clarity, I’ll use an example app throughout the rest of the post. I’ve always wanted a robust gardening app, so we’ll run with that idea and call it Juniper. If you don’t have your own idea yet, steal this one. 😉I’d love to keep my outdoor plants alive (there’s no hope for Andrew, app or not).

👉Already done this stuff? Great! Skip down to our step-by-step process. Otherwise, dig in here first.

Who is this for? Defining a target audience

This is the most important question. Unfortunately, a lot of founders answer it with “everyone.” That’s lazy thinking, and you’re better than lazy thinking.

Your target audience is always a specific group of people with a particular set of needs. “Everyone” is not a target audience. Not even Apple or Netflix are for everyone.

Of course, that’s easy to say and much harder to define. Especially since identifying who you are for means defining who you’re not for, and that feels like leaving opportunity on the table. But from experience, we know positioning yourself to serve a specific market can:

• Clarify your message and make it more persuasive
• Make prioritizing features much easier
• Keep a better grip on spending

My target audience for Juniper is 25-40 year olds who own or rent land in the continental US, are new to gardening, and need help growing outdoor plants. (Note I’m not serving the house plant devotees, pro gardeners, or the retirement community aspiring to landscapes worthy of a Southern Living cover.)

👉Stuck here? Justin Wilcox from Customer Dev Labs has stellar advice and a great process you can work through.

Once you know (or think you know) who your target audience is, you need to get out there and talk with them. Remember, your goal is to build what customers want to pay for, not what you want them to pay for. To do that, you need a really clear picture of who your customers are and what they want.

If you’re not already talking with customers, here are a few helpful resources that will get you started:

• Corey Haine’s guide to customer research via Baremetrics
• How and when Buffer does customer research
• How to interview customers via CustomerDevLabs
• Amy Hoy’s Sales Safari

Whatever you do, don’t skip figuring out who your target audience is and talking with them. Remember, no market need is the #1 reason most startups fail! So talk with the people you want to serve and figure out their needs.

Why does this need to exist? Creating a value proposition

Defining your audience and talking with customers will help you craft another important piece: your unique value proposition.

This is the way that you, and only you, deliver a specific value to your specific audience. If you have competitors, a value proposition helps customers understand why you’re the best choice for them. If you’re in a new market, it helps customers understand why you exist and are worth paying attention to.

In the context of a product roadmap, a value proposition helps clarify what you’re building and why it should exist.

Juniper’s unique value proposition is: Finally find your green thumb. Juniper is everything you need to keep your outdoor plants alive and thriving.

(It’s a work in progress. 😬)

What type of app will it be?

Imagine calling a pest control service and hearing this response: “So tell me. Are you sure you need our services?” You’d never hear that from restaurants, hotels, or retail, either. But in app development this is a CRUCIAL question. If you’re going to succeed with an app, then your startup has to actually need one.

Keep in mind there are native apps, web apps, and hybrid apps. Native apps are the kind you download on your phone. Web apps can be desktop or mobile, and they run inside a web browser (like Chrome or Safari). Hybrid apps are both native and web-based, but they only have one codebase.

Which one you need depends on who your users are, what kind of data you want to manage, your budget, and other factors. Check out the flowchart below for extra guidance.

Juniper’s customer’s will pull up the app several times a week in the yard, at Lowe’s, in the carpool lane, and other not-at-your-desk situations. And since I’ve raised a friends and family round (the photos of my dying plants were very compelling), I have the budget I need to pursue a native app.

👉Still iffy on on what kind of app you need? These questions will give you more guidance.

What are your parameters?

There’s only so much time and money you can spend building your app. Those are parameters and they establish boundaries around what you can and can’t do. Write them down, so you keep your product roadmap realistic. For example, if you only have 3 months to launch your product, don’t create a 6 month roadmap.

For Juniper, I have $100k in budget and 6 months before the next Spring season.

Our step-by-step process for creating a Minimum Loveable Product roadmap

Once you’ve sorted through the who, what, and why above, you’re ready to tackle our step-by-step process for defining your Minimum Loveable Product, or MLP.

A Minimum Loveable Product is a complete story; it has a clear purpose and just the right set of features. It’s not minimum releasable crap or a barely functional piece of a bigger idea. Rather, it’s an insanely valuable package of one or two core functionalities that let you start small, gather feedback, and build up to exactly what customers want.

Step 1: Find a whiteboard, a box of markers, and a few hours

If you don’t have or love whiteboards, you could also create a Trello board or Kanban board in Airtable. Whichever method you use, create three columns: MLP, v2, and manual.    

Here’s what each column means:

• MLP stands for Minimum Loveable Product. This is what you want to create with your roadmap.
• v2 stands for version 2. This is everything you want to build but shouldn’t fit in your MLP.
• Manual identifies all the features you’ll do by hand or with a Wizard of Oz approach.

If you have a team, make sure you get a few key folks in the room. Definitely your co-founder, if you have one.

I’m the only one leading Juniper, so it’s just me, my soy latte, and a Kanban board in Airtable.

Step 2: List every feature you can think of

Once you’re all set up, dump all those features bouncing around your brain into the MLP column.

Need a recap on features? Your product delivers benefits to customers. Features are the tangible, technical way you deliver those benefits. Google docs, for example, provides collaboration. That’s a benefit. Commenting and revision history are both features; they deliver the collaboration benefit.

So in this step, you want to list every feature you can think of. This is your opportunity to go big and crazy. Try not to ask “does this make sense?” or “is it feasible?” Those questions aren’t helpful right now. Rather, you want to get everything out of your head and into this column.

Features most folks forget:

• Forgot password
• Account management (updating your email/password)
• User management (adding, deleting, inviting users)
• Email notifications
• Search Pagination
• Filtering information
• Empty states
• Billing (how are people going to pay you?)

We also include some items that aren’t technically app features but are still essential to launching your MLP. For example, branding and a marketing site.

Step 3: Move as many features as possible to v2

Once you’ve gotten everything down—and preferably taken a lunch break—you want to come back and start moving those features around.

At this stage, one of the best questions you can ask is, “How long can we hold off on this feature?” If you can hold off, even for a week, the feature goes into the v2 list.      

‍With Juniper, a lot of the features I originally listed are nice-to-haves. They add some value, but they aren’t high-impact for the customer (based on what I know so far) and the MLP is functional if I remove them. So all those nice-to-haves get scooted over to v2.

4. Move as many features as possible to manual

Go through your MLP list again and look at every single feature. This time, ask yourself, “Can we do this by hand in the beginning?”

If you answer yes to anything, move that card to the list called “manual.”

Remember, it’s okay to do things that don’t scale. Consider Stripe. One of the reasons Stripe was so much better than competitors was because they made setting up a merchant account easy. And guess what? They did merchant signups manually when they first launched. If one of the most successful companies of the past decade can launch with manual processes, why can’t you?

Our client Case Status launched with manual signups and manual payments; the founder would send an invoice to each customer at the beginning of the month. Later, when Case Status wanted to automate things, they built a typical self-serve purchasing flow. Guess what? Sales went down. They’re now back to implementing customers manually (although invoices are automated).

Maybe you can use Zapier to connect some processes. Or maybe you can process some data manually, but make it look like it’s happening automatically. Doing something manual for now doesn’t mean you’ll do it this way forever.    

It’d be tedious, but I could manually create and categorize a robust plant database for Juniper. Sound crazy? It’s not too far off what the founders of Pandora did. They categorized 450 attributes for thousands of songs in a massive spreadsheet when they started out. I think I could handle some plants.

Note: If you have the budget, a secret second way to automate a feature is hiring someone. If I really didn’t want to categorize those plants I could pay someone on UpWork to do it for me. But personally, I’d rather my money go towards compelling features.

5. Repeat, using these guides

Once you’ve gone through steps 1-4, take a break or sleep on it. Then come back to it the board and repeat steps 3-4. If it feels difficult, you’re probably on the right track. Simple takes a lot more work than complicated.

When you get stuck, the questions below will help you move through the sorting process. If you answer “yes” to any of these, move the feature in question to the v2 list.

• “If I remove this, does the product still solve the main customer problem?”
• “If I remove this feature, does the product still function?”
• “Did I add this for my own satisfaction?”
• “Do I want this because it’s sexy and shiny?”

Remember, the beautiful thing about software is you can deploy an update in a matter of days or weeks. If you’re on the fence about a feature, move it to the v2 list. If your customers complain, build it and launch it one week in. This works in your favor. You’re showing customers you’re listening and you validated that feature.

Our client GreyNoise used this strategy to wow early adopters of his product and generate word of mouth buzz. Sometimes he would build a feature and turn it around in a matter of hours. How’s that for customer support?

Another useful tool is this framework by Gusto’s co-founder. If a feature isn’t high-impact, it shouldn’t be on the MLP list.

Image via Gusto’s Comparing Apples and Oranges

You want to repeat the process of moving items from MLP to v2 or manual until you feel like you can’t take anything else from the MLP list.

Then you want to do it one more time. 😁

6. Sketch out all the screens in your app

To make sure you get everything down, the last thing you want to do is draw sketches of screens you’ll need in your MLP. Don’t worry about making these pretty, and don’t spend a ton of time on each image.

You do want to use this as an opportunity to catch any feature you forgot. You don’t want to add a whole new list of ideas to your board.

Essential screens that are easy to forget:

• Log in
• Create account
• Forgot password
• Onboarding
• Search
• Menu
• Success
• Something went wrong

👉Ready to give this a shot? Here’s the free airtable template. Look for the Copy Base button to make a copy of our Airtable setup and use it on your own account.

What to do once you’ve defined your MLP

First, if you’ve made it this far, you need to take a celebratory moment before you do anything else. 🎉 You’ve just put a lot of energy into asking hard questions most founders aren’t willing to tackle. Well done!

Now, here’s what you can do with all your information.

Get an accurate quote from developers

If you’re working with developers or an agency to build your app, you’ll need a quote.

To make this process easier, transfer your MLP list to a format where developers can easily add their estimates. We use an excel spreadsheet for this, but you could also use Airtable or Trello.

Check out our free Google Sheets template. 👀

To estimate projects, we use T-shirt sizes:

• X-small tasks = 3 hours
• Small tasks = 6 hours
• Medium tasks = 9 hours
• Large tasks = 12.5 hours
• X-large tasks = 25 hours

We also recommend including some buffer in your final estimate—we’ve already included one in the template for you. Remember, something will go wrong, and that’s normal.

What if the estimate comes back over-budget?

Have an honest conversation with your developers. Our recommendation is to always compromise on scope, not quality. You want to take a hard look at the things you don’t think you can do manually and decide how much they’re really worth. For instance, is it worth $10k to send invoices automatically…simply so you don’t have to? Probably not.

You should also research whether a third-party or no-code tool could accomplish certain features or functionality. For example, many founders go overboard on an expensive marketing site when a nocode landing page, like Carrd, would work just fine.

Create a flexible product roadmap for building your MLP

After estimates, you’re ready to start building your MLP; you’re ready to execute. To manage the build, create a board system like the one we used above to define your MLP.

One simple setup that’s easy to use, reference, and manage is called “Now, Next, Later.” As the name implies, you have three columns.       

The Now column contains items you’re working on now. The Next column contains items you’ll work on next. And the Later column is everything you’ll do, well, later.

👉Ready to give this a shot? Here’s the free product roadmap template in Airtable. (It’s the second tab.) Look for the Copy Base button to make a copy of our Airtable setup and use it on your own account.

Note: We use a setup that’s a bit different because we’re an agency with an entire team (designers, developers, founders) working on each project. If your operation is smaller, try the Now, Next, Later approach first. If you don’t like it, dig into all the Product Roadmap templates FYI gathered.

Roadmaps aren’t a “set it and forget it” kind of thing

Remember how we said roadmaps shouldn’t be a bajillion pages?

Besides the fact no one will read any document that long, you’re going to need to update your roadmap frequently and a bajillion pages is something you’ll update…never.

Plus, when you start implementing, you’re going to run into all kinds of unexpected things:

• Budget conflicts: “oh sh%t, we need a domain name…and juniper.io is $6k”
• Technology challenges: Amazon changes their API
• Customer revelations: “huh, everyone uses their weather app for rainfall”

All of which means your roadmap will change. That’s a good thing. But it also means you need a tool that’s easy to work with and a roadmap that’s easy to adjust, or your roadmap will be pretty useless about a month into execution.

Our templates are in Google Sheets and Airtable because those are both easy to use and manipulate. Trello is another fantastic option. Use whatever you’re most likely to revisit.