I've never written a line of code beyond "Hello world."
Not that I wasn't interested, but once on the Product Management track, my time was always more effective in speaking with customers, defining strategy, and executing the vision.
While I focused on the 'why' and the 'what,' I always let the experts focus on the 'how.' But with a slight break in my schedule and curiosity about no-code tools, I took the opportunity to experience building software from an engineer's perspective.
Plus, I thought it would be fun to see if I could take an idea the whole way.
My goals were relatively simple:
Goals:
- Learn and leverage no-code tools to build a simple, functional app
- Expand my technical skills
- Gain a deeper appreciation for the work of my engineering colleagues
Non-goals
- Aesthetically pleasing UI
- Scale to support 1,000s of users
The idea
Consider this; you are in a heated debate with your best friend with no end in sight. If only you could survey a bunch of people to settle it once and for all. Enter 'Ask The Crowd,' a social polling app that allows users to posit questions to a community of voters.
Sure, Reddit, Twitter Polls, Instagram Polls, etc. exist; however, we thought it would be fun to pull out the poll functionality into a standalone app - shout out to Dan G. for the idea! At a minimum, it wasn't a bad idea and was simple enough while having adequate substance to make for a worthwhile endeavor. And I could see how it might be fun and engaging if it gained traction.
Product hat first
Building software products is an art form in and of itself. There is no right way to do product work so long as the outcome is clear, concise, and easily communicable. Given the nature of this project, I skipped step one of market research & understanding my customer's pain points.
I started by mapping the general UX. Creating the visual piece helped get the juices flowing; however, sometimes, I begin with writing user stories. Whether drawing or writing, the best thing to do is pick the medium that allows you to flow and get started.
Using Sketch, the wireframes were basic but would serve as the app's foundation. My focus was primarily on UX - when and where to display information and how the user navigates.
I also started writing out the individual features and breaking them down into user stories during this process. Taking the time to break down features into unit deliverables can sometimes be a pain in the neck, but it's always worth it.
For features that were beyond the scope of v1, I logged them and moved on.
The visual below for what an MVP should look like, is one I revisit often. It's great because it reinforces the agile methodology of delivering early and often.
However, I've worked on projects where the MVP bloats because 'viable' means something slightly different to each stakeholder. So I found it useful to break down Minimum Viable into distinct groups.
The updated language gives the space to say, "hey, all this stuff is important, but here is how we can break it down even further."
For my Earliest Testable Product, the features and functionality I landed on were:
- Submit a Poll
- Browse Polls
- Vote on Poll
- See Poll results
Engineering hat time
My initial foray into engineering wasn’t coding but planning – go figure. With a solid understanding of what I was building, I realized I needed to map out the components to get a general sense of how the system would flow.
I’ve never designed software architecture before, but laying the pieces out visually in Lucid helped refine my thinking – even if it needed massaging later.
During the architecture design process, one immediate appreciation for engineering surfaced. Going through, I considered how I might implement the features that weren’t scoped for the Earliest Testable Product. It helped me see firsthand how engineers strike a delicate balance between building for the future while delivering now.
For me, it meant baking in the concept of Poll Status and Users into the architecture and database schemas for future use.
Tool selection
This article was my jumping-off point for researching the various tools. Ultimately, I landed on Backendless for three reasons:
Frontend and backend capabilities
Building the front and backend in the same tool was exciting because I could pour my energy into that one tool and ideally have a short feedback loop.
Also, I wasn’t up on figuring out how to integrate two separate tools – although now I would feel comfortable making those API calls.
Web App, iOS App, Android App
Three for the price of one!
Coming from a world of distinct iOS and Android engineers, I thought writing the frontend once and deploying it as a Web, iOS, and/or Android app was incredible.
Backendless Viewer App is 🔥
The Viewer app lets you push your app to their already published app in the respective app stores. It’s beneficial for early feedback without going through the process of publishing your app as a standalone app.
Documentation
I bet if Backendless took the time to write the above article about top no-code tools in 2022, they would have good documentation for newbies.
The community support board, countless videos, and ‘missions’ to learn were educational and expansive, so I was able to build my app
Building with no-code
Admittedly, I was a bit fooled by the term ‘no-code.’ I’m not sure what I was expecting, but it’s worth saying that even with these tools, you are absolutely coding. Although, it’s a visual syntax with pre-defined containers and under-the-hood magic that simplifies many of the initial hurdles of typical coding.
Be prepared to learn and apply the basics like If/else statements, loops, variables, API calls, managing data – the list goes on, but it’s all very consumable. That’s not to say I didn’t spend hours watching and re-watching videos for concepts to sink in, but with enough time, it all began to resonate.
For example, here is an IF/ELSE snippet from the Poll Submission page where I am taking the user’s inputs, which are stored locally in “Form Data” and saving that entry as an object in the Polls database in the backend.
One of the things I love about coding is the no BS factor. When it's right, and you understand it, it just makes sense. And then, you can apply that knowledge to future problems by leveraging your new building blocks. Plus, seeing multiple ways to implement a feature helped me genuinely appreciate what 'clean code' means.
Some features changed from the original wireframes, which is to be expected. For instance, I realized I could gamify the experience by displaying the poll results once a user voted. Fortunately, getting alignment between Product, Engineering, and Design was seamless. Hello, consensus, party of one.
The video at the top of this post displays the app in action, but you can also play with it by downloading the Backendless Viewer App in the Apple and/or Google Play store and selecting "Ask The Crowd."
Conclusion
Some people suggested I learn to "actually" code when I started. But I wouldn't change a thing. These tools taught me a TON about software development and how it all connects. Visual development with no code allowed me to learn and deliver much quicker than the traditional route.
Funnily enough, this process reinforced just how vital Product's role is in delivering great products. From early research & understanding of customers' needs to clear documentation and acceptance criteria, it lays the foundation for efficient engineering development. When product work is done right, it's worth its weight in gold.
For now, I am letting my Earliest Testable Product ride. While much functionality is yet to be added, I accomplished my initial goals and am ready to tackle what's next.
