The Value of Going Codeless
We started Codeless because we want to change the way startups and small businesses bring ideas to market. With Agile Development techniques, we iteratively bring products to market faster. Using Lean Startup philosophies, we help remove waste and focus on bringing the right product to market. And with codeless technology, we make building software more accessible.
Speed. Focus. Accessibility.
These are the hooks upon which Andrew and I hang our (metaphorical, and very pink) hats.
But what about that jargon we just used? Lean Startup? Agile? What do these words mean?
This post is my interpretation of a variety of resources, including, but not limited to, the Agile Manifesto, The Lean Startup, and months’ worth of banter on Slack with Andrew.
To help illustrate the terms and concepts, I’ll share the example of building our business, Codeless, and its attendant website www.gocodeless.io.
Before we get started
Why are we sharing all of this stuff? Isn’t this our “secret sauce?”
Well, yes. And no.
We’ve both worked at companies in the past where employees were slaves to the software that was available or given to them — they didn’t even see that there was an option to build their own software cheaply.
Nothing would make us happier than seeing more people pick up tools like these and start using them. You can create something that makes you money without ever having to learn to code or pay someone else to code. But if you think you need help; we’re here for you.
We understand these methodologies deeply. This is our passion. We want to help other people apply them in a way that makes sense.
We’re not afraid of you running off with these tools on your own. But if you have any questions about what you should build first, who your users are, how to optimize your business, how to identify and test your assumptions, how to apply these methodologies — you should contact us. This is what we love. This is what we want to share.
Agile Development
Agile Development is a method of project management characterized by division of tasks into short phases of work and frequent reassessment and adaptation of plans.
Or, as I’ve heard many times recently:
Agile means we’re building the plane as we fly it.
What Agile Development really means is that the project — your software product, an event you’re hosting, a business plan — continuously responds to change. Agile is a framework to unpack your project into short-term, bite-sized chunks of work, and then use the completion of each chunk to inform the next pieces of work, which you document in your “backlog,” or list of future things to complete
An assumption of Agile is that while you might have a rough plan of which piece of development comes first, as you build your product, business, or service, you will necessarily have to change, add, or remove work based on unexpected stimuli. To achieve this, multidisciplinary teams work together and are accountable to the success of the project as a whole, rather than each individual component.
The contrast to Agile is sometimes referred to as “Waterfall” development. It’s a sequential approach: first you define business requirements, then you design your product, then you develop it. In waterfall, multidisciplinary teams only take ownership for their specific part of the project rather than the project as a whole. Business owners define requirements, and then hand off to the designers, who then design the product and hand off to the developers, who then write the code and ship it six months later. At which point, of course, the business owners and designers throw up their hands and exclaim “this isn’t what we wanted!”
Imagine you’re hiking the Appalachian Trail. You’re at the starting point in Georgia. Do you meticulously plan out every day of your 2,100 mile trip? Every meal, every rest stop, everything? Let’s hear from the Appalachian Trail Conservancy on this approach to planning:
A detailed day-by-day itinerary is not necessary for a successful thru-hike. In fact, it can set you up for a lot of discouragement and frustration. There are many things out of your control that can alter your plans, on a thru-hike, such as weather or injury. Sometimes you may find an opportunity for a once-in-a-lifetime experience that sets you back. It’s important to remain flexible.
— Courtesy of the Appalachian Trail Conservancy
Planning everything out in detail beforehand is Waterfall. Sounds like a waste of time. Sounds like you’re setting yourself up for failure. How possible is it for you to achieve such inflexible goals? This is an example of focusing on the wrong thing.
However, you still should have a general idea of your plan. You know you want to go north, to Maine. Perhaps you want to be in a particular state or county for July 4th. But you should build uncertainty into your plan, allowing yourself the flexibility to change course, take a rest day, or explore something awesome as it comes up. From the same paragraph:
An outline of when you expect to reach specific milestones will be helpful to friends and family back home. It can help keep you on track, too.
Agile is all about planning, but in a way that acknowledges you will always know more this week than you did last week. Agile optimizes for fast, constant feedback loops, and as we’ll see below, Lean helps inform those feedback loops by optimizing for learning.
Lean Startup
The Lean Startup methodology de-risks businesses by focusing on learning as a currency.
The term “lean” comes from Lean manufacturing, originally implemented in Japanese automotive plants. Toyota created a relentless focus on only completing work that added value to the customer. All else is considered waste, and removed from the system.
Eric Ries pioneered and conceptualized lean in the startup context in his wonderful book. I highly recommend reading; it fundamentally changed the way I think about business.
(If you’ve read it and want more, Ash Maurya built upon the concept in his more prescriptive Running Lean and, soon to be published, Scaling Lean.)
Now that I’ve gotten those references out of the way — what does it mean to “remove waste” and “focus on learning?”
Ries came up with the Build-Measure-Learn feedback loop below. This is the essence of Lean Startup: every startup business decision should have learning from customers as the primary goal.
Another way of thinking about the feedback loop is: think, make, check. The goal of a business, especially a startup, is to get through the loop as fast as possible. I think people with ideas tend to spend a lot of time thinking, or even a lot of time making. Think-think-think, or make-make-make misses the crucial step of learning, or checking, to make sure that what you’re thinking and making are things people actually want. And more importantly, things people want and will pay for.
This is where Lean influences Agile; Agile development incorporates the learning part of Lean to inform development cycles.
Essentially, it’s a mind-set shift for entrepreneurs. Instead of running a business, you should think about your startup as running an experiment.
Presumably we’ve all gone through the third grade, so the scientific method should be familiar to us:
- Ask a question or develop an idea
- Construct a hypothesis
- Test your hypothesis with an experiment
- Analyze your data and come up with a conclusion
Every startup starts as a hypothesis. To test your hypothesis, Lean Startup recommends you borrow from the philosophies of lean manufacturing and Agile — namely, choose to test your hypothesis using the least amount of work possible. Do not spend an extra second, an extra cent, an extra single drop of sweat if you don’t absolutely have to in order to learn from your test.
This is the most difficult thing about the Lean Startup.
Lean is great, but it’s most great for startups because it most helps companies without a lot of capital by focusing on the smallest possible incremental learning opportunities. This is in contrast to the vast resources required to invest in long development (waterfall) cycles.
A few final thoughts on Lean and Agile:
- You can practice Agile without practicing Lean
- You can practice Lean without building software
- With codeless tools, you can practice Agile without building software
Your idea doesn’t have to be a technology product. For example, food trucks are a great way for restaurateurs to get started by testing their recipes. It’s a lot cheaper and faster than renting restaurant space and hiring a full kitchen staff.
Often, the best way to validate your idea also has nothing to do with software or technology. It’s probably as simple as talking to people.
The thing to remember is: optimize for learning, and enforce fast feedback loops to incorporate change. That means learning and checking as often as possible, and spending as little time and effort thinking, making, and building each successive feature of your product or business.
Most entrepreneurs have a vision — awesome clarity of the wondrous world they’ll create in the future, once their product or business comes to life.
We hope you get there!
We also hope you start at the beginning.
Focus. Start small. Learn through the smallest possible increments, and use that learning to come up with new ideas to test. Keep the customer at the very center of your efforts, always. And talk to your customers as frequently as possible.
The Codeless Experiment
At Codeless, we had an idea of a problem we might be able to solve: small businesses and startup founders have trouble solving business problems with software, because they don’t know how to code and hiring developers is stupidly expensive.
We also had a hypothesis: the codeless tools we discovered, combined with our product consulting expertise, might help these business people bring their ideas to life faster, cheaper, and more successfully.
Finally, we identified the riskiest part of our idea: would people pay us to provide advice and guidance?
So, we tested our hypothesis and riskiest assumption. Andrew put www.nocodestartup.com onto the web in a handful of hours, and we both shared it on our Facebook pages. In a day, we generated more than 20 responses. Remarkably, in our relatively small social circles, we got three sign ups that started legitimate conversations about codeless development of tools to solve real-life business problems. These are people who are willing to pay money for the type of help we’re offering.
Our conclusion: more confidence that there is a market for Codeless, that we can compete against freelance developers, and, most importantly, that it’s worth us spending more time and effort building our business.
This conclusion led us to a more solid business idea — a product consulting firm that utilized codeless techniques coupled with Lean and Agile methodologies to help startups and small businesses build software and/or improve business outcomes. At this point, Andrew and I wanted to build a more robust website. There are a lot of things that went into building our Codeless website: secure a domain, choose the codeless tool to use, and figure out how much — and what type — of content to put on the site.
Rather than defining all of this upfront in a huge expenditure of time and energy, we broke it down into small chunks. We set ourselves a deadline. We created a backlog of “to-do” items with “user stories” that defined what type of customer each to-do would provide value to, and how. We chose our tool (Bubble); bought a domain we liked (www.gocodeless.io); launched a “straw man” website with a pink background and some basic text; and we chatted endlessly about the problem we’re solving, our target customer (hopefully you!) and our value proposition.
The website is still in progress. But that’s the point. It will always be in progress, and we’ll always update it when we learn more about how it provides value to our customers.
Instead of focusing on a plan, we developed a vision — and then planned as we went along. We achieved short-term goals and produced small amounts of work at a time. As a result, we accomplished a lot more of what we wanted, a lot faster than an ostensibly more “rigorous” planning and development hand-off.
Codeless Technology
Codeless Technology is just what it sounds like: tools that help you create applications on the web and mobile devices, without writing a single line of code.
This is the most fun for us. This is where the magic happens. While Agile and Lean are absolutely critical to ensuring the right business or product comes to market (and iterates) fast, codeless technology means that anyone can do it.
Accessibility is the single greatest barrier to building software. Code is literally another language. General Assembly, a fairly well-known code school, has a 12-week full-time program to learn Android, for example. So first, quit your job and sign up for three months of no income. Then, pay them $13,500. Ouch.
Andrew and I don’t fit that group. Chances are, neither do you.
It turns out that code is also super expensive if you want to buy it from a software shop or hire a freelancer. According to Gigster.com, a no-frills social network web app takes about 4 months to build and will set you back around $35k. Double ouch.
Do you have $35k lying around to spend on a speculative app idea? Neither do we.
This is where codeless tools come in. Andrew, bless him, stumbled across Bubble on Product Hunt. With a minimal amount of digging, we found other tools like Neonto, Weld, App Press, BuildFire, Construct 2, and Buildbox.
Suddenly, to folks like us who love technology, but don’t know how to code, a whole new world was opened! We can go well beyond simple website builders like WordPress and create full-fledged applications, including back-end databases, with the click of a mouse.
We (by we, I mean mostly Andrew) built our website using Bubble in about 15 hours total work time, including planning. Beyond the customer-facing pages, it’s got data tables and separate login pages for everyone that’s signed up to “start a project.”
Granted, our expertise is product management. It helps to start in a place where “data tables” isn’t foreign. Our passion is building great products, and we’ve had a lot of experience working with developers to get the right things built in the right ways.
But damn, these codeless tools are so easy.
For us, this was the kicker. We believe these tools are so easy, they make software accessible to anyone.
Let’s work together to figure out what to build, how to build it, or just to bounce some ideas around.
We’re here to help you bring your ideas to life.
