Every Digital Product Starts in the Same Place—With an Idea
An idea that sticks in your craw (as we say here in the South), and won’t let go. An idea that strikes in a moment of clarity, or one that slowly takes shape over time. An idea that stands up to endless poking and prodding, questions asked and answered, and examined from a multitude of angles.
After years of working in startups and mentoring folks in the startup world, I can tell you that the best ideas are born out of problems.
Maybe it’s a small problem in your day-to-day life (i.e., always hunting for your partner’s keys brought us a product like Tile), or a problem that if resolved would greatly impact your company’s efficiency and collaboration (such as cloud-based file-sharing, i.e., Dropbox). Intentionally looking for and digging into the pain points in your daily life, your community, or your industry can be a rich place for digital product ideas.
No matter how great you think your idea is, just having an idea isn’t enough to pull-off a product build. You need at least some of the aforementioned people and processes to build a product. And in order to pull together the resources and expertise that you need, you’re going to have to communicate your idea and your plan in a compelling way.
This Isn’t a Guide About How to Hone Your Elevator Pitch to Land Venture Capitalists
There’s a lot of ground to cover between initial idea and elevator pitch—practically an entire ecosystem of information, concepts, and strategies such as innovation accounting, cohort analysis, growth engines, actionable metrics, customer validation, validated learning, value propositions, BHAGS, OKRs, MVPs… the list goes on and on and each one has their own line of books, podcasts, articles, blogs, and Twitter experts to sift through. It is overwhelming and the sheer wealth of information could be enough to make you want to hurl your idea into the ocean and run far, far away.
But if that idea keeps coming back to you, or never really leaves. If you are convinced there is something there. If you’re ready to take on the monumental task of building a digital product. Then I am here for you.
My goal with this article is to help you navigate the startup landscape, avoid analysis paralysis, and give you a framework for forward progress. There are some great concepts and processes out there that you should explore as you cultivate your idea and we’ll pick and choose from some of the best ones so you can keep moving towards bringing your idea to reality.
The concept is to build something that you can test, test it, and then learn from those tests to allow you to make decisions on what you need to build next. However, if taken too literally, this process can be extremely expensive, an ineffective use of resources, and could crush your entire endeavor before you really get off the ground.
Every Product’s Goal Is to Reach a Solid Product/Market Fit.
Your idea might be amazing, and might solve a real problem for you, but it is just a hypothesis. Many entrepreneurs fall in love with their solution, spend a bunch of precious resources designing, building, and releasing a product onto an unsuspecting world and find that it falls flat on its face. Unfortunately this is the fate of most startups.
Instead of this big bang approach, you’ll want to take smaller steps, and slowly adjust to reach a good product/market fit. It might feel like this process would take longer, especially if you’re convinced that your product is a perfect fit for the market, but it is the constant learning and adjustments that ensure that you don’t move too quickly in the wrong direction.
Below is a diagram of what it looks like when you build out a product, but are moving in the wrong direction, and then have to pivot. It can be a very costly mistake as opposed to moving in small and measured increments.
The Roadmap
As we’ve noted before, there’s a lot of ground to cover on our way to a solid digital product, and many ways to get there. There are a lot of flashy billboards along the way that promise quick results, immediate feedback, and guaranteed success. We’re going to avoid those — they’re tourist traps.
But do feel free to take a pit stop if there’s an idea that’s presented in this next section that seems really intriguing to you — a little more exploration in that area may be just what you need to follow through on your journey.
If you’re familiar with the concept of “Design Thinking,” then you probably recognized these as roughly the same steps that you’ll see outlined as the phases of design thinking. I am going to walk through these different steps and talk about some of the approaches that I think can help you keep moving through the process.
Find Your Problem
As we mentioned earlier, the best ideas for digital products are born out of problems—those pain points in our processes or daily life that repeatedly slow us down or cause irritation.
Look around at your own life, your family, your commute, your schedule, your work, your hobbies. Consider your organization, your industry, your conferences, your networking opportunities. Where are the trouble spots? When do nerves get frayed and who does it affect the most? What systems run smoothly while others just can’t get off the ground? Is there a pattern?
I really wish I could offer more advice on this topic. But until you’ve found a problem that is urgent, and that truly solves a problem for someone, you should probably stop here. However, I have a strong feeling that if you’re reading this, you are already well aware of a problem that is just dying to be solved. Onward!
Be intentional about looking for problems in your day to day life and you’ll likely find plenty of ideas!
Define the Problem
Maybe this has happened to you You’re pouring out your heart to a close friend or partner about a particularly difficult situation and before you even finish talking, they’re cutting you off so they can tell you what you should do (“What you need is…”, “Let me tell you about the time I…”, “You need to talk to my friend who sells…”) As supportive as they’re trying to be, they’re jumping to offer a quick-fix, uninformed solution when what you really need is someone to just listen and understand.
In startups, as in relationships, jumping ahead to the solution without doing the work of listening to the problem is where things can start to veer off course. So this is where we begin the work of defining the problem that you’re trying to solve — and that’s not the same thing as solving the problem!
The goal at this point is to start learning. In order to start learning, we have to start with a hypothesis about what problems we are trying to solve. Write down a few of them, and don’t get too hung up on whether they are right or wrong for now.
A few examples of the hypotheses could be
Finding recipes and making dinner when working parents get home from work is hard.
It is too challenging for coworkers to share large files with each other in a secure way.
It is so hard to regularly keep in touch with your extended network of friends.
Remember, we’re not looking for solutions, just the problems. Stay open to possibilities, and as the saying goes… fall in love with the problem, not the solution.
If you’re feeling challenged with your problems, or you just want to dig in a little deeper into the topic, here are some helpful tools available that you may want to explore.
Lean Canvas does a great job of helping people refine a product’s business model. Check out the “Problems” section as a jumping off point (see below).
Five Whys might be a helpful framework for trying to get to the root causes of your problem.
Try your hand at writing a formal Problem Statement, and see if that helps you identify and explain your problem.
Empathize With Others
The next step in this process is to shift our perspective a bit and think about the problem from the viewpoint of possible customers. This could look like a simple list of target customers and users, but I think it’s worth digging a little deeper to form a clearer picture of your users, because from here on out “User Needs” are the source of truth that we’ll come back to over and over throughout our journey. It will serve as the “north star” for our future decision making.
To start off, just list out the possible groups of users that you think might want to use your product.
You can call these “customer segments” or “user archetypes” or whatever you want, but the point is to get to a list like this
Lawyers in large natural gas companies
Owners of pet grooming businesses
Fraud analysts working in medium-sized financial services companies
You should try to be as specific as possible with these customers. Having a list of the top four or five is usually good, because you can only focus on so many people’s needs. You’ll want users that are specific enough that you can imagine a person that would fit into those roles.
As you proceed with the process, it can be incredibly useful to actually think of imaginary people that represent these roles. People in the UX industry call these Personas. Personas are a tool for defining the major groups of users for your product, and allow you to design your product with a particular set of users and needs in mind, which is incredibly valuable. Being able to design some functionality and then test that functionality against the needs of your personas allows you to quickly gut-check your designs.
However, creating true personas requires finding potential users and interviewing those users, which can be time and resource-intensive. If you are able to do that, then awesome, go do it!
But, to quickly bootstrap this process, Jeff Gothelf coined the term “Proto-Personas,” which is simply the process of creating hypothetical personas that you can use to launch your process and then refine later.
There are thousands of blog posts, training courses, and books on creating personas, but here are some basic attributes, and examples, to consider as you get started
Don’t get too hung up on figuring out the “right way” to put this initial version together. The value here is in thinking deeply about the types of customers who could be using your application, and why they would get value out of it.
Defining these proto-personas will allow you to dig deeper and really start to think about whether the problems you came up with in the previous step really were the set of problems you’re setting out to solve. If, after you’ve defined your proto-personas, you’re still confident in the problems you defined, then feel free to continue on—otherwise go back and spend some more time with them until you feel good about them.
If you feel like you’re completely making things up, and you don’t feel good about your proto-personas at all, then maybe it is time to get out and go talk to some folks that might be users of your product.
The value here is in thinking deeply about the types of customers who could be using your application, and why they would get value out of it.
Generate Solutions
Time to dream.
Congratulations! You’ve finally made it to the part where you can begin to think about possible solutions to your problem. This is usually where most entrepreneurs start, so you can pat yourself on the back for forcing yourself to back up a bit and really start at the beginning.
So let’s dig in What do you think it would take to solve the problems that you’ve defined? At this point, we’re still keeping it very high-level—we’re zoomed out, at 30,000 feet, and thinking big picture. We’ll break it down later on. For instance, if your problem was “Sharing large files is hard,” then your solution could be “Software to allow files to be sent to friends with one click.” Be sure to come up with a high-level solution for each part of the problem you defined earlier.
Once you have your list of solutions, quickly check that list against your proto-personas. Do the solutions you’re thinking of meet the needs of the proto-personas you defined? If not, then think about whether you need to go back and define your problem even more, or refine what you already have.
Let’s Be Honest, Did You Have a Solution in Mind When You Started?
Is that the same solution as what you just wrote down? Do you feel like you refined your solution at all by thinking about your possible customers? If not, then there are two possibilities here
Your solution is amazing, you’re perfectly on target.
You’re really caught up on your solution, and it is clouding how you think about your problems and your customers.
I know which one I think is most likely.
But in either case, it is always a good idea to go out and find people who might be your customers and talk to them. Try not to ask leading questions, try not to suggest the solutions you already have in your head. Just ask them what their problems are. If you can’t get them to talk about their problems, then tell them your problems. Ask them if the problems you’re describing are actually a problem for them. Usually this will get them talking.
Only once you’ve really exhausted the discussion around the problems they are facing should you broach the idea of your solution.
Just remember, everyone is going to tell you that your idea is good. No one likes to shoot down someone else’s idea.
Genuinely ask them how your proposed solution might help them. Try to get them to be specific. Tell them it won’t hurt your feelings if they don’t like your proposed solution (even if it is a bit of a fib). Ask them if they will pay money for it. Do whatever you can to elicit an honest response from them.
Turning Solutions Into a Product
If you’re feeling pretty good about the problems you’ve defined, your set of customers, and about your proposed solutions, then you’re probably ready to move forward. Our next step is to take those high level solutions and break them down into high level features. Sometimes a helpful tool here is what design folks call a user flow. At its most basic level, a user flow is the series of steps a person must perform in order to accomplish a task. Going through this process step-by-step for each of our high-level solutions is how we come to understand what we really want to build—it’s all about learning and understanding.
A small example user flow for a food delivery app
You don’t necessarily have to create a graphical representation of a user flow. You can either sketch them out on paper, or you can just start by creating a list. The point is to start thinking about how a person might accomplish one of their goals within your solution. As soon as you create one of these flows, you can start to think about what are the individual features that you’ll have to build to let a user complete the flow.
Try to capture the high level features that you think your customers will really care about. You can spend a ton of time here, and you can build out a feature list that is a mile long, but that usually isn’t very helpful at this stage. If you do end up with a very long feature list, then you’ll need to think a bit about how to whittle your list down.
The features you define will look something like this
Search a list of restaurants
View a restaurant’s menu
Add an item to your cart from the restaurant’s menu
Refine Your Solutions
One of the easiest tools that I have found for whittling down an initial feature-set is to plot all of your features based on impact vs cost.
This is also a great conversation to have with people in your life who may be possible users (family, friends, co-workers), because the primary value here is the conversations about the impact of different features, and the associated difficulty with implementing them. And in order to get the most value out of this process, it’s important to talk with an experienced software engineer who can help you estimate the effort of implementing the features you’ve come up with.
Clearly, the best possible set of features is a grouping that is almost exclusively high impact and low cost — you definitely want the most bang for your buck. However, it’s incredibly rare to put together an initial prototype from all high impact/low cost features. You can expect that you’ll need to include a few high impact/high cost features as well as those wonderful high impact/low cost features.
But don’t get too worried if you have a lot of high impact/high cost features, just because something is high cost doesn’t mean that you have to implement it right out of the gate. You can always use manual methods to fake features until you’re ready to invest more effort. People often refer to these as a “Wizard of Oz” Prototype.
While maximum effectiveness at minimum cost is important when it comes to narrowing down your feature list, you don’t want to lose sight of the “complete experience.”
Take a look at this now famous drawing by Henrik Kniberg
The idea here is to build a small but useful product, and then keep making it larger and more feature-filled until you have a product that your customers love.
You can’t just build an isolated feature and continue to add other fully fleshed-out features until your product finally works. You won’t learn anything or gain any customers along the way. As an example, pretend you’re building a file sharing product. You couldn’t just build out the file uploading piece without building a sharing mechanism, the users wouldn’t get any value from this and so it wouldn’t provide you with any learning.
In order to stress this point, some people in the industry have started using the phrase Minimum Loveable Product instead of Minimum Viable Product to bring focus to the idea that you need to build something that a small number of users really love, rather than setting out to build something that a large number of users merely like. Trying to build out a series of features to tackle a really big market might seem like a great idea, but you’re almost always better off tackling a smaller market and then moving upstream.
Prototype
Have we finally traveled far enough on this journey that it’s time to jump out and go build something? Well, no. This happens far too often, especially from startup founders who are software engineers. I’ve been there. Engineers want to build things, and they see building something as a way to test out an idea. If you’re an engineer, and you just want to build something, then by all means go and build it. Just don’t pretend that it is always the fastest and easiest way to test and iterate on your idea.
For many types of digital startup products, prototypes are the way to go. You may have heard the terms wireframe, mockup, prototype, etc… and the differences can be a bit confusing. They are all visual representations of your future product, just at different levels of fidelity. There isn’t a ton of agreement, and so you’ll sometimes hear people use these terms interchangeably, particularly mockup and prototype. I like to think of a wireframe as a very low-fidelity view, a mockup as a static high-fidelity view, and a prototype as an interactive version of a mockup.
There are a lot of amazing tools out there to help you build out your prototype (we particularly enjoy Figma), and if you have the skills to use those tools, you should absolutely pursue that. However, for most people just getting started, it isn’t realistic to go learn one of these tools just to start this process. Instead just grab a whiteboard, or a piece of paper and a pen!
What’s the most important thing to get out of a prototype? Yep, you guessed it…learning!
A hand-drawn prototype might not be as slick as a digital prototype, but if you’re able to create something that will let you and your prospective customers imagine what it would be like to use your product, then you can learn quite a bit!
While it is true that digital prototypes allow you to iterate faster and help your users feel like they are using a real product, don’t get stuck feeling like you absolutely have to create one. Just remember to start small. I can’t say enough how important it is to start simple and slowly ramp things up. Don’t go big at the beginning and build out a large and detailed prototype before you start putting it in front of people. If you do this you’ll fall into the sunk cost trap, and once you get attached to it, you won’t be able to throw it away…even if your users are telling you it isn’t meeting their needs.
Test, Then Iterate
Start small, start simple. Create a quick and dirty prototype, show it to people, do some learning, and then iterate on it.
Keep doing this until you feel good about your prototype. When building out your prototype, you’ll probably get to a point pretty quickly where you’ll want to show it to someone. And please do! Show it to someone as early as possible. Don’t let perfect be the enemy of good!
If your instinct is to hide it away until you’re “done,” you’re going to have to force yourself to overcome this. This is the fear of ridicule or failure biting at you, and if you want to launch a product, you’re going to have to find a way to start referring to failure as learning, because it really is the same thing.
When you’re asking for feedback on your prototype from potential customers, be sure you’re focused on doing real learning and not just looking for affirmation or reinforcement of your own assumptions. As I mentioned earlier, most people won’t want to offend when giving feedback, so you might not hear that your idea is bad or your product is unusable. Be willing to read between the lines of their feedback to get to their true feelings. Ask open-ended questions that allow your customer to consider the product from their own perspective, and not through your own, highly invested lens. Allow your potential customer to work their own way through your prototype without any of your input and make sure you’re asking questions to try to prove your assumptions wrong.
You want your product to hold up to scrutiny, so as uncomfortable as it may be to put your baby out there, know that this process is meant for good—either your product will hold up and flourish, or you’ll know that it’s not ready yet and you can walk it back and iterate again.
One critical piece of information to gain from this part of the process is whether people will pay for your product. As soon as you’ve refined your prototype to the point that it is starting to feel real, ask people to put down real money in order to be a customer when it launches. Lots of people will tell you your idea is great, and that they love it. But when you ask for money you’ll quickly start to hear their objections.
But that’s not failure—it’s learning! If people are finding reasons not to pay, find out what those are, and iterate again. Even an objection as innocuous as “our company policy won’t let us pay for products ahead of time,” can be a learning opportunity. If your product can be the solution to a painful problem they are having, they are probably going to be brainstorming ways to get around company policies, rather than using them as an excuse to end the conversation.
So now you’ve put your prototype in front of a few people, hopefully potential customers, and you’ve started to get feedback.
Based on that feedback how does it affect your initial assumptions?
Does it change how you think about your users?
Does it change the problems you’re trying to solve?
Does it change the solutions you’re proposing?
If you still feel like you’re headed in the right direction on the items listed above, then maybe it just changes the implementation of your solution?
If so, go back and update your prototype and check in with the same folks again. After a few rounds of this you can expand and iterate on your prototype until you’re in a spot where you feel like you have a prototype of an MVP that you can get excited about! Maybe it doesn’t have all of the features you want, maybe it feels a little basic, but that can be a good thing.
As long as you’re excited, and your potential customers are excited, you’re probably in a good spot to move on to the next step.
What’s Next?
There are a few directions you can go from here
Build it The first, and most obvious option would be to start building out your MVP. If you’re able to build it yourself, or you can get someone to build it for you, then this might make sense. Just be realistic about what you can accomplish, and aim for getting something minimal to market that people will love. And try to do that in a really short timeframe.
Raise money Friends or family that are willing to chip in is how many startups get their initial funding. Others will find investors who are willing to invest in their idea, but this is much rarer unless you have a ton of specialized expertise, relationships, experience, or are a smooth talker.
Don’t build it, fake it! Some startups are ripe for what we referred to earlier as a “Wizard of Oz” experiment or what people call a “Concierge MVP.” If you start small, you might be able to manually make the whole thing work until you have some customers under your belt. For certain types of ideas, you can get pretty far with a Google Form wired up to Zapier. Once you have some learnings and a few paying customers, finding funding can be a much easier prospect.
Just remember, once you start building, fundraising, or experimenting you’ll still need to pay careful attention to the learning that occurs along the way. Don’t get so wrapped up in the direction you’re heading that you ignore what investors or customers are telling you.
You need to continue to focus on the build, measure, learn cycle and keep prototyping, testing, and iterating as you go.
Great Software Is About People, Not Code
Thank you for taking the time to read through this guide. We hope that you took something away from it that can help you in your product journey. For us, building digital products is about understanding the people involved, what they need, and what drives them. If you always keep your focus on that, you’ll go far. If you ever need help, feel free to reach out, we would love to hear from you.
The post Bootstrapping a Digital Product appeared first on Simple Thread.
+1 (216)-435-0788 
contact@ernestech.com 
