If you are a new no-code maker - which was me at the start of ODNC1 - this is for you! As Anthony Constantino reminded me, it can be very helpful to learn from those who are just a step or two ahead of you in the process, moreso than more than advanced practitioners. So hopefully my reflections will be useful to you.
On the creative process
There’s a lot of great guidance and playbooks on creating software products out there. However, if you put too much effort/thought into “doing things right,” you will find yourself overthinking and losing momentum. Be ruthlessly willing to screw up, produce something shitty, and fail. Short of tempting real disaster, making the mistakes yourself is a better way of learning to avoid them. So ask yourself - is there a disaster on the line if I make a mistake here? If not, prioritize speed and “good enough.”
If you’re doing something new and learning new tools, you will find yourself getting stuck. Yes, you. Your job is not to hold to some pure, illusory linear path of progress. This notion is a trap. Your job is to get unstuck when you find yourself stuck, rinse and repeat. Set micro-goals, and celebrate your small wins like hell! (Check out Microbrave created by Glen McWhinney and Mark Bowley).
Part of this - and this is I think an art and not a science - is when to persist, and when to simply find an easier substitute or focus on lower-hanging fruit that allows you to keep moving forward. The latter is often misunderstood as a failure. Disabuse yourself of this notion.
Set fixed points
Maybe you’re still figuring out what you’re working on - fine. Try to apply a deliberate filtering process to that, too. Keep in mind that a fixed goals raise your level. Processes/systems come second. Setting and committing to a fixed goal is scary in new territory. I encourage you to do it anyway.
Set up daily/weekly OKR’s
I’d encourage you to set up both weekly/daily habits or processes. Arpit Gupta created a nice template for this. Some suggestions might be: #/tweets per week, find a way to be helpful to others everyday, or similar.
Make it a place where you share your doubts and keep it real. These don’t need to be all patting each other’s backs.
Make friends like Sam Bailez who’ll ask you hard questions in a friendly way, like: “what specifically is the gap between my working prototype and a sufficient MVP?” It’s one of those obvious questions that you may not have a clear answer to as often as you’d like. You will avoid addressing it by yourself. Scope creep in MVP’s is something even experienced PM’s struggle with. Use your mastermind to keep it in check.
If you decide you need to learn Bubble - which definitely has a significant learning curve - here’s what I’d recommend:
- Do the lessons that Bubble funnels you to when you first create an account.
- Muck about trying to build what you had in mind for a week or so.
- Take a step back for a few days to focus on more extensive tutorials/courses.
- Return to your project with a “sharper tool.”
- Program in pairs with people that are at a similar skill level.
- Ask for help from more experienced Bubblers.
It is easy to spend a lot of time being stuck with Bubble. My MVP was 80% done for about a month. This is my biggest regret of ODNC. Yes you need to spend some time heads-down on your own problem-solving, but don’t let your pride get in the way. Prioritize speed.
Some helpful no-code resources:
- Carri Craver’s No Code Products
- Michael Novotny’s Side Project Stack
- KP’s No-Code Cheat Sheet
- Micah Johnson’s Getting Started on Bubble guide
- Kieran and Pablo’s Bubble Crash Course