Development

Advice for Non-Technical Founders

Creating a product is an often complex process that requires a mixture of skills to ensure things run smoothly. One of the necessary skills is technical ability. So how should you proceed as a non-technical founder?

My goal with this post is to utilize my experience as an engineer and entrepreneur to give advice to non-technical founders who are working with external developers to build their products.

How deep is your understanding of technology?

As a non-technical founder, your main priority is obviously not learning how to code. But you must have some understanding of technology. For example, as basic as it sounds, if you are creating a mobile app for iOS or Android, you should at least own a smartphone. (This probably sounds funny, especially to founders in the US, but I’ve seen this happen with clients.)

Try to review examples in order to learn the concepts involved with your product. You don’t need to learn the actual programming language, but just familiarizing yourself with some of the basic concepts will allow you to better communicate with your technology partner and to understand the feedback that you receive from him or her.

This advice also applies to shortcuts that developers sometimes take, such as utilizing cross-platform tools (for example, to build for iOS and Android simultaneously). It’s possible for those types of tools to help, but only in specific cases. In order to truly understand and evaluate your developer’s recommendations, you should read up on the pros and cons of that type of approach.

Has the idea been validated?

It can be easy to fall into the trap of thinking that your idea is the best and that no one else has thought of it before. That’s why it’s important to consider these questions before you begin working with a developer:

  • Is it really true that no one else has tried building this product before?
  • If so, why not? (For example, the answer may be that there isn’t really a market for the concept.)
  • Who will use the product? How large is the potential user base?
  • How will you make money?
  • Which features will comprise your Minimum Viable Product (MVP)?

Do you understand the development process?

Understanding the development process is a key component of creating your product. You can have a disruptive idea and talented developer but still end up with a mess if there is not a clear sense of how the product will actually get built.

How involved do you want to be?

When it comes to building your product, the developer team will follow some type of process (e.g. agile, scrum, etc.). If you want to be highly involved, it’s important for you to understand the ins and outs of that approach (including aspects like how often code will be pushed and the process for review and feedback).

Even if you don’t have the time or inclination to understand all of the details, be sure that you are aware of the various stages (e.g. prototyping, visual design, coding, testing, etc.) so that you can track the progress your team is making.

Based on my experience, it’s better for non-technical founders to be involved throughout the process, so they can see how the product is evolving and get feedback at each stage, which will make it easier to make any necessary changes along the way.

Better done than perfect

Non-technical founders sometimes focus more on making the product perfect than on having it finished. The perfectionist impulse is understandable – after all, this is your baby. But I have witnessed many good products go bankrupt because of the quest for perfection.

This happened to one of my former clients. They wanted to have absolutely everything done before launching. We tried to explain that the idea is to launch and fail fast, gather feedback from users and then pivot if necessary. Unfortunately, they ignored our advice and we ended up spending a year re-designing the product three times, only to have them run out of funding by the time the process was finished.

I understand that it’s hard to launch something that’s not perfect, but it’s even worse to launch nothing at all. That doesn’t mean you should launch a product riddled with bugs, but instead try to truly launch an MVP (emphasis on the “minimum”), so that you can get feedback and then continue working with your technology partner to make improvements.

What is your feedback loop?

Feedback is the most critical part of product development. After all, how can you improve without it?

Here are some tips:

  • When soliciting feedback, be sure to target the individuals or businesses that you hope will become users of your product.
  • Be sure to share feedback with your development team so that it can be incorporated into the next sprint or phase.
  • Not all feedback will be equally important. Be sure to differentiate between comments you hear repeatedly from potential users and “nice-to-have” features that were only requested by a few.
  • Try not to get upset if the feedback doesn’t match what you wanted to hear.
  • Be specific about your target audience. For example, “kids” is not the same as “kids between ages 8-13.” (I saw that mistake a lot with mobile games.)
  • You can collect feedback in a variety of ways, such as conducting in-person interviews, recording reactions of a group of potential users, or sending out surveys.
  • And don’t feel like you have to wait until the product is finished to get feedback! You can use wireframes or mockups to measure potential users’ reactions in the meantime.

Start selling early

Don’t wait until the product is finished to begin selling, especially if you’re building for the enterprise!

Building customer relationships takes time. This means that, after a couple of months of development (if you’re lucky!), you still might have to wait weeks or months until you begin getting prospects. So that’s why you should take wireframes or a slide presentation and start selling while the product is still being built.

I remember that we once sold a product after sending a mobile mockup (completed in about five hours) to the prospect. They liked it and bought it, and then it took us three months to deliver. Bottom line: don’t waste any time.

Does development ever really end?

Assume that development is an ongoing process even when you have the main feature set completed. Technology itself is ever-evolving, and your product must keep up!

A few things to keep in mind:

  • iPhone apps will need to be updated as Apple releases new phones (especially with different screen sizes) and new operating systems.
  • Android is also likely to release new operating systems, which will require app updates. In addition, Android has a large variety of devices, and you will likely need to increase the number of devices you support as your product and user base grows
  • If you have a web product, you will probably need to make updates as changes are made to the browsers (e.g. Safari, Chrome, Firefox).
  • And last but certainly not least, you should never stop collecting feedback from users so you can ensure future versions of your product continue to get better and better!

Featured image credit

Ready to start your project?

Learn how ThinkApps can get your product launched faster, better, and with more value than you knew was possible.

@ThinkApps on Twitter