Figure out what to build
Have an idea for the next great app? Translate it into the functionality and UI that you will actually be building.
Last updated
Have an idea for the next great app? Translate it into the functionality and UI that you will actually be building.
Last updated
Building on Bubble is easy. Well not really "easy" but certainly much easier than coding something up from scratch. And it can be quite fun. As the result, Bubblers often jump straight into building features as soon as they have the idea. That's usually not the right way.
After you create the initial feature list, the first question you should ask yourself is which features you can eliminate from the list and still have a workable product. Most successful products started off doing very few things but those few things hit on a major pain point or a need that their consumers were experiencing. Here are some reasons for this:
It takes longer to build more than it is to build less, so you will waste time and effort building things that aren't critical.
Complexity is exponential because the more functionality you add now, the more future features will need to interact with that functionality, which will make future work more difficult.
People like using simple products. If you pack yours full of functionality, you risk people abandoning it before they've realized how great it is. Instead, start small and add features over time, which will allow your users climb up the learning curve more slowly.
Adding features later is easier than removing features later. Even if you realize that something you built is unnecessary, you'll have to identify all of the places where it needs to be removed and most likely there will be someone who will complain.
So you've ended up with a list of absolutely necessary features. The next question is - can you do something manual to start to mimic those feature without building a fully automatic solution? Let's look at some examples:
If you're building a platform that needs an internal messenger, you may want to transition users to email instead of building a full in-app messaging experience (or you can always plug in our messenger module if you're using Canvas ).
If you need a complex matching mechanism, you could start by making the matches yourself in the backend manually.
If you're building a two-sided marketplace, you could start by not allowing one side to sign up automatically. Instead you could have them email you and you could just manually create an account for them in the backend.
If you need to pay people in a complex way, you could start by doing so manually outside of the platform.
More generally, you could try to plug-in existing tools (i.e. Calendly for scheduling, Typeform for forms, etc.) instead of building something from scratch.
Spotify says it best with this illustration of how products should be built:
Many of us have been guilty of fooling ourselves that if we build a really great solution to a problem, people will find it and use it. That's just not true 99.99% of the time, the rare viral hit being the exception. Many great products have disappeared into oblivion due to poor sales & marketing and many shoddy products have succeeded because someone sold them well. You absolutely must have a plan of how you'll plan to get people to find out about your product and how you'll get them to try it. This applies whether you're building a startup or a product for an existing company. If it's the latter, you'll obviously have an easy audience but you'll still need to convince them to use the product and keep using them.
Your features may also end up getting shaped by your distribution plan. For example, you may want to build in viral loops into your product where referrals result in some sort of a benefit to the referrer. Or you may build customized landing pages for each of the big potential customers you're going after.
Bottom line, think about how you'll see as much or more as what you'll sell.
You've got your list of features - does that mean you're ready to build? Not yet. The next step is creating a wireframe outside of Bubble. "Waste of time!" you may exclaim, "Bubble is easy to use, why not just design in it right away?!" There nothing inherently wrong with wireframing with Bubble, as long as 2 things are true:
You don't actually connect your functionality because the functionality is likely to evolve through the wireframing process
You're quick at Bubble design because there are tools out there that are easier and quicker to wireframe in
One of our favorites is a classic - Balsamiq. Wireframing in it allows us to refine our product vision through the process and quickly adjust things on the fly.
And, of course, you should keep some design principles in mind through your wireframing process:
As you get sucked into the Bubble world, it's very easy to forget about people and spend hours/days/weeks/months just building and polishing your product. Don't do that. Instead, even before you start building, go talk to people. Tell them about your planned features, show them your wireframes, ask them about pricing, etc. but talk to them. You're likely to get valuable feedback that will help you refine and improve your product before you've placed your first Bubble element.
On the other hand, don't listen to everything that everyone tells you. It's easy to second-guess yourself based on feedback from others but, at the end of the day, you have to have conviction and a product vision. Some of the best products came out of something that most people thought was a bad idea, so ignoring advice is sometimes as important as listening to it.
This is a hard but important balance to reach - you have to have the hubris to try something people may not agree with but the humility to know where they might be right.
This is a pretty small point but, once you created your features, wireframes, etc. and are seemingly ready to start, wait a day or a few. Sometimes just by procrastinating you will come up with a simpler/cleaner/more creative way to do something.
