November 21st, 2022
How to create a successful digital product from scratch
The following article describes a single process. A problem-solving methodology specifically tailored for the creators of digital products. It should go without saying this is an opinionated piece. There are many approaches to this fascinating and ever-changing discipline. At the time of writing, this is what I consider to be the best approach.
It is a combination of my formal studies in product design, what I’ve learned firsthand as the head of design for Bitwala and a combination of the mistakes and successes I’ve seen leading my own product design agency.
Modern product development is an enormous subject. Here, I’ve done my best to reduce things down to their most essential. The do’s, the don’ts, and the fundamental principles that really matter. So, without further adieu, let’s dive in together and explore: How to create a successful digital product from scratch.
Scope: This article focuses specifically on all things product. We’ll exclude other essential factors like incorporating, fundraising, and marketing.
Aspirations: The process presented strives toward these ideals:
- Lean: maximal results for minimum resources
- Low-risk: reducing risk as much as possible without inhibiting performance
- Versatile: the process can be applied to digital products across all industries
Who’s it for: Startup founders. i.e. individuals that have a vision for a digital product they want to bring to the world, and intend to raise funds through venture capital to realise this.
Timeframe: My experience (and passion) lie in the earlier stages of product development. This article covers the journey from idea to approximately Series A.
One of the most difficult things about creating a digital product is, despite having a strong vision for what your users want as you set out, it is likely very difficult to visualise exactly how the final product will look and feel.
Solving a problem with a fuzzy definition can be extremely challenging. One of the reasons the process we’ll explore is so effective is because it is excellent at crunching uncertainty. Together we’ll take the journey from fuzzy idea, through to tangible final result. All in a methodical predictable way.
We’ll name the collection of methods and techniques used to achieve this our ‘product process.’
There are several fundamental concepts we’ll use to orientate ourselves along the way. The first concept is called fidelity. ‘Fidelity’ is an industry term for the resolution with which we can perceive our solution.
An example of a lo-fi (low fidelity) solution is a wireframe.
An example of a hi-fi (high fidelity) solution is a final mockup.
Our process will start at lo-fi and as we progress, the fidelity of our product will constantly increase. Like something that starts out pixelated or blurry and slowly comes into focus. Fidelity is often used to describe the user interface (UI), but the concept can be applied right from the start. In fact, our initial product idea can be considered a low-fidelity concept. Here’s a short clip of Netflix’s founder Marc Randolph talking about getting started with just a piece of paper, a sharpie, and some tape.
Always solve the challenge at hand in the lowest possible fidelity.
We do this for (at least) two reasons:
- It ticks both the ‘lean’ and ‘low-risk’ aspirations of our process. We want to identify and eliminate a bad idea as fast and as cheaply as possible.
- Clarity. Low fidelity strips things back to the essentials. Once the interface is all dressed up, a bad idea can be harder to detect. So we don’t just work in a coarse resolution because it’s fast. We’re also intentionally removing clutter. This way, a bad idea has nowhere to hide.
There are two fundamentally different sub-processes used throughout our larger process.
- Creative process: 0 → 1
- Iterative process: 1 → n
The ‘creative process’ is great at getting from zero to one. It creates something out of nothing, or dramatically re-envisions an existing thing. The ‘iterative process’ evolves. It consists of a series of frequent smaller adjustments over a period of time—it optimises. A common mistake is to use these two interchangeably when in fact they have fundamentally different modes of operation. We will explore each of these in context later on. But for now, just remember they are unique and not interchangeable.
Never confuse process types: Are we creating or optimising?
Our product process can be divided into four sequential phases. Each uses different methods to solve the unique challenges of that phase.
- Ideation - Creative
- Product exploration - Iterate
- Get scale-ready - Creative
- Product development - Iterate
Before we dive into the details, let’s zoom out for a moment. Our objective is to create a successful digital product. We’re not 100% sure what that will be yet, but we have some strong opinions, loosely held, that we’re ready to test. To help us on this journey into the unknown, we have our product process. It is specifically designed to navigate through this uncertainty as effectively and predictably as possible.
The remainder of the article will explore this process, taking a deeper dive into each of the four stages mentioned above. We’ll clearly define why each stage is important, best practices to employ, and common mistakes to avoid along the way.
Henry Ford said: “If I had asked people what they wanted, they would have said faster horses.” He of course gave them the automobile. As a founder, it’s important that you have a vision for what your audience requires. Something they are unable to imagine yet. The clearer your vision, the easier it will be to bring to life.
As important as your vision is, however, the people that decide whether or not your product is of value are of course your users. No amount of marketing and sales will compensate for a deeply flawed product. With such stakes, it would be foolish to completely ignore your user’s voice.
And herein lies the challenge. Both these two opposing forces are 100% real. Without a clear founder’s vision, you’ll find yourself spinning in a whirlpool of opinion, or worse, lost in the dark. On the other hand, the longer you work in isolation the greater the risk of creating something users don’t actually want.
The answer is of course balance. We’ll call this ‘bifocal vision.’ Throughout the entire product journey, you should be gathering (external) user feedback and reinforcing your (internal) vision. This constant balancing act is one of the most complex challenges to get right. At different stages of the process the weighting between the two swings back and forth. But remember, over the long run both are essential.
A strong vision and user feedback are necessary.
As this is such a fundamental component of the product process, I think it’s important to touch on this subject. However, my understanding is that the journey to vision is incredibly unique and differs greatly from person to person. I would say that typically the vision actually comes first and that is what drives the person to become a founder. It is likely a distillation of life experience, industry experience, and preliminary research. These factors (and no doubt others) at least in my experience, formed a strong ‘gut feeling’ that slowly swelled until I had enough belief to step out into the unknown.
An excellent technique for navigating uncertainty, is to frame smaller segments of exploration. This looks very similar to the scientific method we learned in school. If done correctly, we won’t go backwards. We either progress, or we learn. The tools we use for framing are:
- Hypotheses: What do we expect to happen?
- Testing method: How will we measure our hypotheses?
- Success metric(s): How will we measure the effectiveness of the tested solution?
What makes this method so powerful is it forces us to be intentional, i.e. thinking and planning ahead. An intentional approach to product creation is the most fundamental concept. It is the core function in our navigation system. It prevents us from getting lost.
Be intentional. What problem are we looking to solve here?
After the test is complete and we have digested our learnings—either validating our hypothesis or learning something new—we are ready to roll again. We update and refine our test, then repeat the process. Altogether, this process is called the ‘build measure learn’ cycle popularised in Eric Reis’ book, The Lean Startup (there’s a good chance you’ve heard of it). It is the engine of constant refinement. Over successive iterations, it is the driving force that takes us from idea to tangible product, bringing our vision into focus.
As you can see, this also knits nicely with the previous section. For at the highest level, our product vision is also a hypothesis.
Something that makes ‘framing’ so useful is its scalability. It works at the global level, framing our entire product (i.e. our product vision). And it works on the local level, framing fine-grain details (like where to place a button) and everything in between.
For now, we’ll stay focused on the top-level challenges. We have our product vision. We’ve broken that down to a set of hypotheses. Now let’s put them to the test.
This begins the second phase of our process, ‘product exploration’. Unlike its predecessor, this is an iterative segment. Here we will start with something—our initial test—and constantly optimise and refine it. So, how to test? Remember principle #1: Always solve the challenge at hand in the lowest possible fidelity. In this sense, there’s no fixed answer. Any method that is lean and effective is the right tool. That said, here are some common tools we can use when testing our hypotheses.
- User survey
- User interview
- Lo-fi click dummy
- Hi-fi click dummy
I think it’s worth mentioning that surveys and user interviews would typically be considered ‘user research’ not testing methods. Here we are referring to ‘testing’ in the broadest sense of the term. Any method that can help us measure the validity of our hypotheses. There are so many methodologies, frameworks, and tools these days it can be easy to get sucked into the details, distracted by labels, and lose sight of the initial goal. The further we progress, the more difficult this becomes.
Don’t lose sight of the big picture.
Most readers will be familiar with many if not all of the testing methods above. Despite this, a common question I receive is, when is the right time to use each one? Actually, I wouldn’t worry so much about the timing. Instead, focus on why. What problem are we trying to solve? Which question are we trying to answer?
Here’s a quick summary of the type of output you can expect from each method:
User Surveys: These are quantitative by nature. Here we should be working with larger sample sets and looking for patterns within the results i.e. averages, favourites, etc. There’s a good chance we know what we’re looking for and are trying to either prove or disprove it.
User interviews: These are qualitative by nature. Here we can have much smaller sample sets than with surveys. We are going deep, not wide. We are looking for insights and anomalies. We’re looking to be surprised.
Lo-fi Click Dummy: User testing sessions with lo-fi click dummies test functional aspects of the product. Everything else is abstracted away, reducing distraction. Here we’re testing content, navigation, and user flows. Can a user navigate easily? Do they ‘get it’?
Hi-fi Click Dummy: This incorporates the lo-fi functional aspects and adds an additional ‘emotional’ layer in the form of colours, fonts etc. Does this branding elicit the desired emotion in the user? Does this additional dimension create emphasis in the right areas?
MVP: Typically an MVP will not look as visually refined as the hifi click dummy, but the functionality will be much more advanced. A dynamic database and all the other things that a ‘real’ product can offer allow us to test more complex functionality. It also shows investors we can actually build.
While surveys and interviews are absolutely important, it can be dangerous to stay in the theoretical world for too long. Users are typically not so accurate at predicting how they will behave (though much better than us guessing). In addition, the scenario we’re describing may be imagined completely differently in their minds.
For these reasons, it’s important to get something tangible into the user’s hands as fast as possible. In doing this we’re aiming to shift the discussion from the abstract to the practical. In fact, this general upward flow toward product clarity is something we should aim to maintain. To raise the fidelity of our exploration as fast as is reasonable.
If test results repeat for too long, you’re likely moving too slowly. If testers are off-topic, or things are getting noisy and confusing, you’re moving too fast. Remember the principles we’ve discussed. By being intentional, you’ll make sure you don’t slide off track. By working at the lowest effective fidelity, you’ll move quickly and save resources.
Before we conclude this chapter, I think it’s worth mentioning a quick word on what’s normal. What is a typical exploration trajectory? To my knowledge, there is none. Although our goal is to start at lo-fi and finish at hi-fi, the path is almost never linear. These are not one-way thresholds that are passed through, but environments of exploration to answer the questions at hand.
Remember, at the end of the day, progress is moving toward clarity, whatever the short-term direction may be.
In other words, this phase of the process is about learning. We’re looking to validate our hypotheses, iterate and refine. With this in mind, the question emerges, how much is enough? When are we ready to transition into the next phase?
It can be tempting to look at your MVP for this. How many features? How many beta users? While product metrics are great indicators, they unfortunately don’t provide much certainty. Fundamentally, ‘how much is enough’ is not a product question, but a strategic one.
We started out with a top-level hypothesis in the form of our product vision. We have since framed and surveyed a vast landscape of potential, learning every step of the way. We’ve refined our understanding of our users’ problems. Refined our various test solutions for them. With this greater level of understanding, a new possibility emerges.
We are ready to transition into the next phase once we want to focus on growth.
If we start driving traffic to a clunky product, we’re going to burn leads. Delay until everything is perfect, and we’ll likely exhaust our resources. Shifting our focus from learning to growth is a massive change with far-reaching consequences. This segment of our process is about making sure we get that transition right.
We are ready to focus on growth, once we have a strong hypothesis for reaching product-market fit, the holy grail of product development. Using the same framing methods presented earlier, we will iterate our way there. Typically, at this point we’ve:
- Built an MVP
- Have a small user-base of beta users
- Have a stack of user insights
- Have a list of new features we can’t wait to build
- Have achieved seed funding
Now it’s time to get serious.
So—we just put our foot on the accelerator and scale right?
Actually, I would advise against this. The beauty of an iterative phase is constant optimisation, but the price we pay for that is ‘debt’. Design debt, tech debt, operational debt. These are industry terms for unwanted mutations during our growth spurt. A bloated code base, conflicting design files, loose threads everywhere. These things weren’t significant enough to fix previously (it’s an MVP after all) but they’re certainly not ideal. The big question is, when to address them? I would argue the time is now.
Typically, a growing user base goes hand in hand with a growing product. It means new features, optimisations, sweeping changes. You are about to get pulled in a thousand directions at once. Which is actually a positive sign; it means you have a passionate user base that is hungry for more. But it will also be… intense.
It’s important to prepare for this intensity. If you just continue on as is and scale the MVP (essentially perpetuating an iterative process) you’ll take the tangled code base and conflicting design files and magnify everything. Dragging all that legacy debt into the future. The next opportunity for a product overhaul will likely not be for some time. Now is the opportune time to take a breath, step back, review and realign everything. It’s time to get ‘scale ready.’
Getting ‘scale ready’ is a transitional period that should be handled thoughtfully. Done poorly (or skipped altogether) and things will grow in an uncoordinated way. Uncoordinated growth might feel like ‘quick wins’ at first, but behind-the-scenes complexity is infiltrating all aspects of our product and increasing exponentially. If unaddressed, the entire user experience will become tangled, our USP diluted, and at this point, users will struggle to understand why our product is relevant. To make matters worse, to maintain this mess everyone will be working much much harder… Sound dramatic? Ask around. This is unfortunately common and should be taken seriously. Product complexity emerges naturally. It takes strong leadership to constantly keep it in check.
Complexity confuses users and exhausted teams—complexity kills startups.
The solution to the chaos is a ‘break and reset’—a creative process phase. To do this effectively we need to consider both the past (all our learnings so far) and the future (where are we heading?) With a clear understanding of both the past and future, we’re able to make some bold updates to our product. Everything that’s broken or redundant is burned off. Everything that is good, is consolidated and realigned.
If done correctly, in a short period of time we’ll have a new and improved product baseline that feels much better than our MVP (for our users), contains none of the previous debt (for our team), and is inherently scalable (for the bright future ahead).
My own product design agency focuses specifically on this essential leg of the product journey. Working with us you get the benefits of senior design knowledge for this critical reset without the ongoing costs of a full-time hire. By the time we finish, your internal team will be empowered to scale independently.
Learn more here
With a clear vision and fresh new product core, we can set our sights on the ultimate goal—product-market fit—knowing we’re giving ourselves the best chance possible.
This phase returns us to the iterative process. The same ‘build-measure-learn’ cycle we used during the ‘product exploration’ phase, but this time the stakes are raised. Users are more demanding and less forgiving. In fact, in subtle ways, many things have changed.
With a focus on growth, user retention is now especially important. Alex Shultz, Facebook’s CMO unpacks this in this excellent talk. Essentially, you can’t have a successful product if your users don’t stick around. We are no longer looking simply to learn, we want to create an experience that will delight users and that they’ll share with their friends.
To cultivate and maintain this level of quality, we’ll be optimising existing features while simultaneously releasing new ones. Up until now, our focus has swung back and forth at various stages of development. From now on, balancing external feedback with internal vision will need to be handled constantly and simultaneously.
Handling all this will require a growing team. Separations into squads. As a founder, you will quickly find yourself less focused on creating a great product, and more on creating the systems and processes that empower teams to create a great product. This level of abstraction is a big change. As things progress, you’ll start to work more with managers than makers.
This brings on another massive change. Governance. With an ever-expanding group of people all excited to contribute to a growing product, how will you digest these diverse and conflicting opinions? How are efforts prioritised? These are company challenges rather than product challenges and are all healthy signs that you are growing. They also indicate we are starting to venture beyond my area of expertise.
A few good words before we part.
Despite all this change, take comfort in the fact that the fundamentals of product development should stay more or less the same. In fact, the bigger you get, the more they matter. The more difficult they are to maintain. The antidote is, of course, process. Process is stability in motion. The tools and methods we’ve discussed will help you navigate whatever terrain you come across.
So, the updated objective is to iterate your way towards product-market fit. A bright future awaits! Don’t lose sight of the big picture. Reduce complexity wherever possible. And wherever you’re at, keep that fundamental question in mind—what problem are we looking to solve here?
November 14th, 2022
Product positioning for early-stage tech startups
November 11th, 2022
Strategic considerations for digital product design
November 7th, 2022
Design systems - what they are and why you need one
Oumnia El Khazzani
SlowLettuce | Copyright 2023