In a couple of previous posts, I wrote about preparing specs and mockups for your product (Part I) and hiring designers and developers (Part II). Once you have your product spec, design and team ready you can start the development process. This step is equally complicated as any of the previous ones, but it can take an unlimited amount of time. If you build an initial version and you see that customers love it and are willing to pay, prepare yourself to an endless process of improvement and refinement.

Manage the product

If you’ve done customer development, you should probably know that there’s a ton of features that your customers would love to see. You’ve probably outlined them in the product spec and asked the designer to create the UI. With a lot of features requested it might be hard to decide where to start from and in what order to build them.

You’ve probably heard about the concept of the minimum viable product. It was popularised by Eric Ries and Lean Startup movement. The idea is to create an absolutely minimal product to validate your idea. The criteria of a valid idea are paying customers. That’s what you should be aiming for. The best way to do it is to cut down all features except the most crucial ones and get the product to users as soon as possible.

I’ll try to show it by example. Let’s say you want to build an app to help accountants track and bill their clients.  You might want to include things like login/signup, user profiles, list of clients, invoice list, ability to create and edit invoices, send them and get paid. In addition to that, you would want to include messaging between the accountant and the client, bookkeeping automation using the AI, and an ability to create a simple website for an accountant.

You need to understand what’s the main job you are trying to help your customers with. In an example above you can start with just login/signup, simple profiles with a name, email, and password and a way to easily create and email invoices. Once you have that working and you have customer feedback and people paying for the app, you can start building the ability to get paid directly through the email and other features.

It’s important to find the balance between the unusable product that doesn’t bring value and a feature-packed beast that takes forever to develop. The only way to do it is to work in iterations and have a ‘launch team’ — several customers that you’ve been talking to during the interview phase who are willing to be early adopters of your app. Their feedback will drive your next steps as you move through the roadmap. Remember — you need to constantly revisit and update the roadmap as your product is being developed and you learn more about customer needs from their feedback.

What to read:

Manage the project

On one hand, managing the software development project is somewhat similar to managing project in other industries, but at the same time, it’s very different because of the high level of uncertainty.

Most of the problems during the project are people’s problems. You need to become a good manager and treat your team (even it’s a team of one) with respect, encouraging them to do the best work they can and helping them during the way.

In the construction industry, there’s a traditional Design-Bid-Build process and a Fast-track approach. DBB takes a lot of time because the design phase requires an architect to study all aspects of the project and create a very detailed documentation. Fast-track is another approach. It has a much shorter schedule but it presents much bigger risks — since the design phase is incomplete the final budget is unknown. Another risk is that work built in an early phase of the project may not suit later design decisions.

It’s quite the same in the software projects. There are two general approaches — Waterfall (similar to DBB) and agile practices like SCRUM. The problem is that no matter how long the design phase is in the Waterfall project the amount of time spent on individual phases is still unpredictable because of accidental complications. An accidental complication is something that creeps into the work because of the interdependent parts of the system affecting each other. Contrary to construction projects, software libraries, languages and services used constantly evolve and predicting how everything will work together is impossible.

That makes the Waterfall approach extremely inefficient — you still spend an unknown amount of time on development, but you also wait too long before development even starts. If your project is even slightly complicated you should consider an agile approach.

The only thing you can be sure of while building your app is that you will be late on almost every feature in the roadmap. With that in mind, you should try to build as little as possible to give your customers most value. As most of the experienced developers know, the best code is the one that is not written. If you can fake some of the inner workings of your app with the human labor you should definitely do that and implement the automation later after you are absolutely sure that the feature is viable.

What to read

Testing and feedback loop

If you are a startup you need to make sure that customers will actually use your product and pay for it. Your goal should be to create maximum value during one or two-week iterations. After the iteration is completed it’s important to test newly built features to find bugs. Don’t slack on testing — the more you test your app the more confident you can be that everything still works. Make sure to run regression tests every couple weeks to make sure that features built previously are still working after new features were added.

You need to build a process where every feature has three phases — implementation, quality assurance testing, and customer testing. That might seem complicated but you really can’t skip QA or customer testing.

If you don’t do QA you will have tons of bugs and will have to spend plenty of time fixing them before launch. Bugs are not something uncommon, even the most experienced developers have bugs in their code — that’s just the way software is. The only way to have bug-free app is to spend time on testing and fixing bugs. Don’t rely on developers to do the QA — most of the times they don’t see even the most simple bugs due to professional deformation. EIther do it yourself or hire a QA engineer.

QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.

Skipping customer testing is also a bad idea. Every feature you build should be tested by your launch team to make sure you are on the right track. The best way to approach this is to have bi-weekly calls with several people who are waiting for your app and hear their feedback on what you’ve built so far.

What to read:

It's easy to write these steps down than to actually implement them. Creating and refining the product roadmap is a serious task even for the most seasoned entrepreneurs. Managing developers and resolving all day-to-day issues is also something that takes a lot of time, energy and commitment. But as with all hard things, the reward is great, and the more you do it the easier it becomes.