In my work as a software developer, and a member of Venture Cafe, I meet lots of folks who want to build an app. Often they introduce the app idea by talking about the features they want it to have; sometimes there are wireframes or screen mockups to look at. In trying to understand a new project I like to take a step back and ask about the underlying process that the app will support. You see, in most cases software doesn’t help a user by offering features (as if a “feature” were a unit of value); rather, software helps us by providing a structured approach for doing something we want to do. Software helps a user carry out a process. Once you get that process right, it’s usually possible to build software that facilitates it; but if you get the process wrong then no matter how well the software is built it’s not going to be effective because the process itself isn’t.
In the past year, I’ve met at least five people who wanted to build an app for staying fit. Obviously, it’s not the app that makes you fit; rather, the app helps you structure and stick with your exercise routine. How does it do that? Well, perhaps it asks you to enter some data each time you exercise, and then it helps you see how well you’re doing. The underlying assumption is that people will get more from their exercise if they can monitor it and track progress. What the app does is to support the monitoring process – the daily work of writing down what you did, the weekly task of reviewing your progress and setting goals for next week.
Is it worth building an app to do this? Often what I observe is that the underlying process does not actually require technology – the technology is just there to make the process more efficient and convenient, so people will be more likely to do it. Therefore, it’s usually possible to test the process and start refining it before you’ve invested in one line of code. In the case of the fitness app, I would ask the entrepreneur: have you ever tried helping someone through this process with pen and paper, or with a spreadsheet? Have you ever helped a friend get more fit by checking up on their daily workouts and reviewing the numbers with them each week?
Now in some cases the entrepreneur might say “Yes, as a matter of fact I’m a personal trainer and this is what I do all the time.” As a software developer, I get very excited at this point and my next set of questions will be all about the person’s training practice and the routine tasks they’re performing manually right now. Here my job is easy because I just need to take an existing, well-tested process, understand it deeply, and find ways to support or automate it with a software system.
But it’s surprising how in many cases, the entrepreneur says “No, I haven’t tried it yet” and then proceeds to give me a pitch about why their app idea is so good, even revolutionary. It’s at this time that I recommend a Process Prototype. Find a few friends or acquaintances and offer them a free service: for one week or one month, do for them everything that your app would do, if it existed. As a developer, I love to assist in process prototyping, but someone who’s trying to get started on a tight budget will usually realize they can do this step on their own if they really want to.
Often people nod and agree that this is a good idea, but there’s an underlying reluctance to actually do it. Jumping into app development is sexy. A new entrepreneur wants to get started and have something to show as soon as possible. Pen and paper, spreadsheets, hours of manual work – not as sexy.
What I say is that if you jump into app development and launch a beta product, eventually it’s going to come back to process refinement anyway: people will try out the system, give you feedback, and you’ll have to revise the software to support a revised process. But think about the cost. It’s much more expensive to build the wrong software and redesign it, than it is to test the process early and build the right software to support it. I’m speaking a bit glibly here, because no matter how much testing you do up front, software development will always be iterative and you’ll always learn something after you’ve launched the app that you just couldn’t have discovered from a process prototype. However, if you’ve invested in a process prototype up front, you’ll go through fewer iterations – and they’ll be smaller and cheaper – before you get something that really works. ■