This post is part of a series about how you can use “off-the-shelf” tools to make online products in a way that prioritizes user needs over the application of technology. Many awesome companies like Compass, Kollecto, and Code for America have described their experiences of “building without code.” I hope to contribute an engineer’s perspective to the conversation.
An engineer’s guide to “building without code”
So you say you want to code.
You may be a designer, you may be a “founder,” or you may be someone with a cool idea for a website or app that could help your coworkers. In any case, you’re a person who wants to make a product on the internet. Well, I’m an engineer; I’m your “technical cofounder.” At a high level, we want the same thing: to make a product that people use , that people LOVE to use. But maybe you don’t need engineers like me to make that product — at least not yet.
Code is merely an amplifier. As an engineer, I cannot magically discover a great product by happening on the right lines of code. I can only realize my team’s vision.
But so many people want to code right away. The problem is that they want to do so before they’ve defined their requirements. The process I’m advocating here — building without code rather than coding — starts with investigating, understanding, and articulating user needs. Coding implies some special knowledge. But ‘building’ is something people can do over the weekend. It means getting your hands dirty and just going for it. To make better online products that people will love, we should teach people to build. But what does that mean?
Start Small
Building is an iterative process that starts with a prototype, a tool to test one aspect of your product at a time. This post will explore the prototyping process for a fictional company. The key here is that we’ll build our digital product with off-the-shelf tools. By that I mean a tool like Squarespace, which provides you with templates for functional websites, or one like Zapier, which facilitates sharing data among other online services. We won’t need engineers or coding at all.
We’ll call our startup “Luigify.” As we all know, plumbers spend most of their time traveling through big green pipes, which can hide various dangers. Our goal is to make a website that helps them navigate these pipes by recommending ones that are reliably safe. So let’s build!
0. Learn to code (protip: don’t)
The first step is learning to code. Jkjkjk.
Starting a pipe-navigation business is going to be very difficult. Between doing user interviews, writing pitch decks, assessing the market, talking to investors, and hiring a team, we not have time to learn how to code. But the plumbing industry can’t wait! We’ve heard of another startup called M.rio that may be trying to do the same thing. How can we get a good product to market first?
Well, maybe we can get top engineering talent to work on our project. After talking to some engineers, we’re quoted $100–150k to build out a personalized pipe recommender over four months. That is just too expensive. We don’t even know how much plumbers will pay for pipe recommendations yet, much less what kind of pipe recommender they want.
We don’t have time to learn how to code, and we can’t afford engineers. So what can we do?
1. Learn to think like a builder
“[Builders] focus on five steps, but the first two are the most important. Step 1 is to ‘empathize’ — learn what the real issues are that need to be solved. Next, ‘define the problem’ — a surprisingly tough task. The third step is to ‘ideate’ — brainstorm, make lists, write down ideas and generate possible solutions. Step 4 is to build a prototype or create a plan. The final step is to test the idea and seek feedback from others.”
— Tara Parker-Pope, “‘Design Thinking’ for a Better You,” The New York Times
Our goal is to understand users’ needs, and then to identify small steps toward addressing those needs. Instead of focusing on our end product and what programming language we’ll use to make it, we’ll consider the underlying problem. To put it more directly in building terms, you might say we’re focusing on the blueprint.
As we start building Luigify, let’s try the first step from that New York Times quote above, empathizing with plumbers to better understand their problem. While we aren’t plumbers ourselves, we know a tiny bit about what they go through. We have heard, for instance, that some pipes lead to rooms full of coins, while others lead to a room full of enemies.
Empathize
One good way to empathize with your users is to buy them coffee and chat. So we start sitting plumbers down and asking them about which pipes lead to coins. Right off the bat, our first interviewee tells us how complicated pipes are — it turns out they’re actually much more varied than we initially thought. Some pipes lead to dangerous areas, sure, but sometimes plumbers actually want to go to these areas. It’s all very confusing. Apparently some pipes even contain menacing carnivorous plants that can eat plumbers! When he brings these up, our plumber gets visibly frustrated. “Those piranha plants are the worst! I wish there was some way to tell if a pipe has a plant in it before I jump in…”
Define the problem
Now we know that, while it would be nice to identify exactly where each pipe goes, plumbers’ biggest problem is simply determining whether or not a pipe houses a piranha plant. Maybe we can simplify and focus our product just on doing that. So our refined goal is to build a tool that will help plumbers determine which pipes contain deadly plants. That’s a clear need, a strong foundation to build upon. But how?
We’ve now identified a meaningful problem and have a clear idea of the product we want to build. But it’s still easy to falter at this stage. Often what holds people back the most is fear, uncertainty, and doubt. We know there’s a need for deadly plant detection, but what if no one shows up on launch day? How will we design and launch anything without being able to hire engineers and designers?
With digital products, we can easily “launch” to small groups of users, and we can then change our product in response to their feedback. Even without code, we can make these changes quickly and affordably (no engineers!). We might eventually need code to scale up, improve the process, or automate parts of the product, but that can wait until there’s a proven need.
“Building — and testing — without tech allows us to focus our engineering resources on problems we deeply understand, saving us time and money.” — Mike Willner, co-founder of Compass
Our second big fear might concern design. There’s a widespread belief that the designer’s task is sacred — that we “lay people” can’t comment on their work. Specialized tasks like branding and logo design should absolutely be trusted to design professionals. (Ahem…Uber.) But functional design is something that you can — and should — understand as a you create a digital product.
While it is still challenging to design for functionality, one great way to approach doing so is to base your prototype on an existing application. Before I go look for a designer, I’ll often use free tools like Sketch Resources or Invision prototypes to find a similar app. I then adjust the model’s design, functionality and content to better match my product.
For Luigify, we can develop a prototype like this, go back to the plumbers we initially interviewed, and ask for feedback on our product’s functionality. We start the cycle of empathize, define, ideate, and build all over again to gain new insights.
There are many real challenges to building something people love to use. But they’re surmountable. We can do this.
2. Build something
“When you are building a business, no one is going to yell at you for using a salad fork to eat a steak” — Gary Chou
Our next step is to invest just enough to test if the general plumbing population really want the service indicated by our user interviews. Our product is informational, so we should create a functional prototype first; we can perfect our design, later. (Note: You should do what best suits the capabilities of your team and the demands of the test. But you will likely need to both create designs and a functional prototype). The easiest way to a functional prototype might be to create a place where plumbers can report piranha plants, and then view one another’s warnings. After considering a variety of tools, we decide to first make a form for reporting piranha plant locations. We’ll use this to source data, which we’ll then send out to plumbers via an email list.
We will combine three tools to do this: Typeform (a website that facilitates creation of custom forms), Zapier (mentioned above) and MailChimp (a website to send personalized emails in bulk). Our Typeform is where plumbers can submit pipe locations and descriptions. (I have a sample up here.) We can go look for some piranha plants and provide the initial data.
Now that we have the data, we need to get it to Mailchimp. Zapier allows us to add an item to an RSS feed whenever someone fills out the Typeform survey. We’ll create a feed that includes all piranha plant reports. We’ll then create a MailChimp email campaign to format, display, and disseminate the feed. We can also use MailChimp to generate a signup form for plumbers to join our mailing list.
Now we have a tool that allows plumbers to both report dangerous pipes themselves and to see their colleague’s warnings via email. It isn’t the perfect solution to their problems, but it is something we can build on. We can ask some plumbers to try it out for their feedback. The next step might then be to create a Squarespace site to explain the service and to direct plumbers to sign up for our mailing list. If things go well, we might eventually make a mobile app that can automatically warn plumbers about nearby dangerous pipes …but that’s a task for another day.
3. Keep building
In some ways, the most challenging hurdle is to accept that what we’ve built is an imperfect solution in every way — and that it should be. This inability to find the perfect solution is a huge part of prototyping. Our goal is not to build the perfect thing , but to learn more about what the perfect thing might be. This prototype version of Luigify represents the first time real people will use something we made. While people’s feedback may sting a bit as they identify problems with our prototype, they will still be using our product. That will give us real, valuable information about the market, and constitutes our first step toward finding product-market fit.
Luigify is just one scenario, but you can imagine the many ways we could apply similar thinking to a variety of businesses. To help do so, I’ve set up a small list of tools for builders.
Thanks to Gary Chou for generally talking me through the process of writing this piece. If you are an independent creator in NYC take a look at his space Orbital.
And huge thanks to Alexander Rothman and Christina Xu who helped edit.
