For every success story featured in TechCrunch or Forbes, there are hundreds of smart, driven, and well-resourced teams that fail to meet the needs of their target users. Sometimes the issue is the core concept itself. Far more often, teams with promising ideas take a flawed approach to product development, thwarting their good efforts.
5 rules for how to build a software product that excites users
Below are a few key principles that our most successful clients follow when launching their products. A quick note: We use Airbnb as an illustration to bring each lesson to life. We hope you find the lessons useful as you learn how to build a software product your users will love.
1. Understand your target audience, but listen selectively
Before you build anything, it is critical that you understand who you are building your software product for and what problem it solves for them. That is why the easiest problems to solve are the ones that you have faced yourself.
Airbnb started because the founders needed to earn some extra money and decided to do so by renting out a mattress in their living room. Solving their own problem first gave them an intimate understanding of (at least one segment of) their target customers, which helped them to identify and address many of the early-stage challenges with their platform.
If you're wondering how to build a software product that solves someone else's needs, simply interview your target users about their needs so you can best address them. There is a subtle but critical lesson in these early conversations: make sure to focus on the problems they face, not the solutions they suggest.
This principle is illustrated by Henry Ford’s quote: “If I had asked people what they wanted, they would have said faster horses.” Your audience knows their problem (get to places faster), but because they may not understand the full range of possible solutions, they often describe the solution that is most obvious to them.
Whenever your users explain that they need a particular feature, you should instead try to get at what problem that feature would solve for them. Often this is simply a matter of asking “why?” Once you have identified the root challenges, then you can widen the scope of potential solutions before settling on the best one.
2. Build just enough to solve your customer's needs
When you have an idea for a product, it is natural to imagine it in its completed future state, with a robust set of features and massive user base. Having imagined this vision for some time, it can be tempting to set out to build that exact product from day one.
The issue with this approach is that the long-term vision for the product is rarely the same thing as the version you should launch with. For example, the first version of Airbnb didn’t even have payments; it simply allowed guests to connect with hosts and the transaction was handled offline. But what that first version did was quickly validate the concept and provide the founders with a lot of learning, which they were able to use in order to eventually build what Airbnb is today.
The key lesson in how to build a software product is that the first version should have just enough functionality to solve the customer’s core problem and nothing else. This approach has several advantages:
- It is much faster and cheaper to launch, allowing you to start learning sooner and save more for future iterations
- Your product will be simpler to use, which means that new customers will be less likely to get confused and leave
- It is easier to identify what is working vs. not working when you have fewer moving pieces to test at once
- You will be more likely to let your consumers drive product development, which will result in a product that meets their needs
- You are less likely to need to remove features and complexity later (which is always harder than adding them)
The approach described above has been called building a ‘Minimum Loveable Product’ (MLP) , one with a limited feature set but one that users will talk about because it solves their biggest need.
3. Create a great (and simple) user experience
Even the first “MLP” version of your product should have a delightful user experience. This is particularly important for consumer-facing apps, as users today are accustomed to a certain level of polish. Below are a few considerations to have in mind as you’re thinking through your user experience (UX) plan:
- First of all, building a good experience and building a simple experience go hand-in-hand. Let’s take a look at the first version of Airbnb in the image below. The design certainly looks outdated today, but the key is that it’s clean and simple to use. There is no confusion about what the user needs to do next: type your criteria and browse a list of results.
- Secondly, you don’t need to spend tens of thousands of dollars making a fancy design to create a good user experience. Instead, the easiest path is picking a design framework that someone else has already thought through and sticking to that design framework, which will result in a product which is cohesive and user-friendly. For example, we use our own Canvas framework in 95% of client applications that we build, to make great-looking products without reinventing the wheel each time.
- Finally, the user experience doesn’t just end at your product. Every step of your process, whether done through software or by humans, should aim to delight your early users. Word of mouth is one of the most powerful ways to get early traction, and a delightful user experience goes a long way in encouraging users to share your work with others.
4. Do things that don’t scale
The whole purpose of building software is that it is perfectly scalable -- adding another user to your platform costs next to nothing since the computer does the work. And so this lesson, borrowed from an iconic article by Paul Graham, may seem counterintuitive.
The key principle in how to build a software product is that in the beginning of a startup the founders have to do a lot of manual work to get users, make them happy, and make their product spread. This seems futile to most founders, because they can’t possibly imagine putting in all that work for every future user as they scale. The key is that they will not have to -- these initial efforts are critical in getting off the ground and increasing the chances of more self-service growth in the future.
Paul Graham's article talks about this principle more in the context of marketing products and getting users, but it’s just as applicable when it comes to your product development. The way this principle applies is that it’s ok (and often better) to build a product where a large part of the process initially needs to be done manually by a person, outside of the product. That approach is obviously not scalable beyond a certain point but can be very valuable in the early stages of a product because it makes it faster to build and it also allows for the process to solidify first before automating it.
For example, a critical part of Airbnb’s host onboarding was that they would book a photographer to come take professional photos of the listed property. In the beginning that process was all managed manually but, as it became solidified and the company scaled, they automated it. Most products should take a similar approach: automating only things that need to be automated in the beginning and doing the rest manually until the process is set and it becomes unwieldy to continue doing it manually. These are known as "Concierge MVPs", and you can learn more about them in our article on building a marketplace without code.
5. Be ready to hustle and iterate
Having an idea for a new venture can be thrilling. As the images in your head gain sharper focus it seems that success is just around the corner.
But your idea is wrong.
It may not be entirely wrong. You may have the right service but the wrong customers, or the right price point but the wrong monetization approach, or the right messaging but the wrong communication channels. Either way, it is extremely unlikely that all (or even most) aspects of the product as you are envisioning it will resemble the optimal version.
This is not to say you will fail. In fact, your wrongness might actually be your greatest source of advantage. Right now, there are hundreds of other people and companies around the world with your idea -- their similar experiences and logic have led them to imagine a product not unlike yours. If your idea was perfect, someone would have launched it already. But because you are all wrong, and because the truly great idea is hidden beneath layers of nuanced learnings, you can gain an edge through your approach to getting to that great idea.
The Airbnb founders had their idea in 2007. Before they got any traction or investment they had to do several redesigns and even at some point created and sold cereal (Obama O's and Cap'n McCains) on the street, to make money that they could put towards their concept. Fast forward to now, when Airbnb is a multi-billion dollar household name.
The key is not to get the answer right on the first try, which is nearly impossible (assuming your name is not Steve Jobs). Rather, the key is to test your product as quickly and affordably as possible, so that you can learn how it is wrong, and on how to make the next version better. By iterating this process, and focusing on learnings rather than outcomes, your path may be winding, but you will maximize chances of success.
Learn more tips to building a great software product
Trying to figure out which features to include/exclude in the first version of the app you’re building? Check out our guide to selecting your initial app features.
Or, if you're looking for professional Bubble developers, we can help: hire us as your full-service Bubble agency or hire individual Bubble freelancers through our Flex program.
.png)
.png)
