Kittrell: 5 frustrations for non-technical founders

You’ve got a great idea for an app — the kind that keeps you up at night.

Ben Kittrell

But you’ve never worked on a software project before and have no idea what you’re in for. Sound familiar? Here’s a list of common frustrations I see from my non-technical clients.

1. Scope creep
No, it’s not a creepy guy using a telescope. Scope creep is what happens when you start out with a simple project and one by one features keep getting added. Before you know it the project, is twice as big and doesn’t seem like it will ever launch.

If you’ve spent any time around tech entrepreneurs, you’ve probably heard the acronym “MVP” thrown around. Thanks to the book Lean Startup by Eric Reyes, the term “Minimum Viable Product” has become a pivotal part of any successful startup’s vernacular. The idea is simple: create the absolute minimal set of features your app needs in order to be viable in your market.

It’s very tempting to say “We need X before we launch.” What you should be saying is “Can we launch without X, Y and Z?” I highly recommend reading Lean Startup for more on this and many other valuable topics.

2. Developers are not created equal
Whether it’s front-end, back-end, social, mobile, web flash or intranet, most developers have a specialty.

This is the same for development firms, which may seem to have a broad expertise but usually have a set formula for building projects. The problem is that by the time you figure out a developer or development firm isn’t right for you, it’s usually too late.

Here’s a real world example from one of my clients. This client wanted to build a social platform with a big vision. The app had many different features, and it needed an innovative interface to handle them. The client found an accomplished development firm owned by the former CTO of a well-known tech company. The idea was to use this firm to build the initial product and transition to an internal team.

After some time it became clear that while the team had a great deal of experience building intranet and enterprise applications, they had little to no experience building social networks or complex interactive user interfaces. In addition, they were using proprietary technology to build the application, a common practice that development firms use to lock you in to their services. Ultimately, the client realized he had spent over a year and $500,000 building an application that just wasn’t right. Very few developers will tell you they’re not right for the job.

3. “Done”
Most of the time, issues between developers and owners come down to communication. A word or idea may mean two different things to two people. One of my favorite examples is the use of the word “Done”.

When a founder says, “Is the app done?” they’re really asking “If I show this to everyone I know, will they have a perfect experience?” When a developer says, “We’re done” what they’re really saying is “I’m done coding, I ran through the first tests that came to mind, and I feel pretty good about it.”

Neither use is unreasonable, but the difference between them can cause a lot of frustration. Clear communication is important between clients and developers to avoid issues.

4. Software always has bugs
Every single piece of software you use has hundreds of bugs in it. You probably experience bugs every day without noticing. You open an app on your phone, it crashes right away and you open it again without thinking about it. You try to post to Facebook and get a cryptic error message, only to try again and it’s fine.

But when it’s your project, a bug can feel like the end of the world. Inconveniences that you ignore every day are now critical issues.

There are obviously different types of bugs and it’s likely that you will encounter a few “Show-stoppers”. However after the developer says it’s “Done” most bugs will probably be specific to a small set of users. Not to say it shouldn’t be fixed, it just becomes a matter of priority among other pending work.

Coming to terms with the reality of never ending bug lists can save you headaches, sleepless nights and grey hairs.

5. Complaints: They’re a good thing
Why? First, it means you have users — hooray! Second, you now have the most valuable information you can get: customer feedback.

It’s hard not to take complaints personally when it’s your product, but what a customer is saying when they complain is “I like your service and want to use it, but here’s one thing that’s in my way.” If they didn’t like it at all they’d just disappear.

There’s a small caveat here. If you address every complaint then you’re going to end up with a terrible product. Not all complaints will come from users in your target demographic. Changing the interface for one user might irritate one hundred. You know your product better than anyone, so never let someone else tell you how it should work. Complaints are suggestions. Take them all in to figure out how it fits into your vision.

Ben Kittrell is technology consultant, working with startups and small businesses. Kittrell also is host of Spare Room Radio, a podcast that features Kansas City entrepreneurs.