What non-technical founders should know about digital product development

I have worked with a couple of non-technical founders in the past and I have honestly learnt a lot from those experiences.

A couple of experiences have been exhilarating - smooth to say, while others have been downright frustrating. This is not to be a jibe at non-technical founders, but rather a mere recollection of my experiences garnered from working with them.

In this post, my focus will be on Tim - a banker who wants to, for example, build a fintech product. Tim is convinced that his knowledge of the financial industry is enough to build a product that will solve the problems of his target users. Furthermore, he has no technical background and is not interested in learning how to code.

What should Tim know about DIGITAL product development?

An image of Steve Jobs and Steve Wozniak, the co-founders of Apple Inc. Steve Jobs was the visionary and business mind behind Apple, while Steve Wozniak was the technical genius who designed and built the first Apple computers. This image symbolizes the partnership between a non-technical founder (Steve Jobs) and a technical co-founder (Steve Wozniak) in building a successful digital product.

Below, I will share 10 tidbits of advice that I think will be helpful for non-technical founders, like Tim, who want to build a digital product.

1. There’s more to a product than just code.

A couple of the founders I have worked with tend to think that only the coding bit is the bottleneck. And rightly so, if they solved it, then they will have a solid business out of their idea forgetting that other aspects such as marketing, distribution, customer support, etc. are equally important.

Sure, at the start of the entreprenurial journey, the product is the main focus, but as the business becomes fully formed, other aspects will need more attention as well. There’s no point in having the most elegant software if no one is willing to use it even if it’s all they wanted to save their lives from the guillotine.

2. Software is iterative.

Software development is not a linear activity. This makes it hard to estimate cost; both in terms of time and money.

If you hire a programmer to “help” build your product, he or she is trying to merge three worlds:

• your vision of what the end product should be,
• the domain constraints of the problem space or industry, e.g the regulatory environment, and,
• the technical constraints of the solution space, e.g the limitations of the technology stack.

Balancing the above is not an easy feat and requires deliberate communication and effort from both the founder and the technical team (could be a single developer or an agency).

The founder and the technical team need to harmonize on their understanding of the problem space, schedules and timelines and most importantly, the deliverables.

3. Avoid hype and buzzwords.

The tech space is known for it’s hype, jargon and buzzwords. Today, it’s AI, blockchain, web5, e.t.c. Tomorrow, it will be a forest fire of new buzzwords.

I have seen some founders get caught up in the hype and try to incorporate the latest buzzwords into their product without truly understanding what they truly entail.

In a forest full of noise and buzzwords, focusing on what your potential customers and stakeholders need is a superpower.

4. Code is a liability

Let’s be honest, code is like a debt that you still have pay back in the future.

The more code you have, the higher the price you will have to pay in terms of maintenance, bug fixing, refactoring, etc.

Take an instance:

You need a marketing landing page for your company or product. You have a choice to make:

• Hire a developer to build a custom landing page for you. The justification is that this will give you a unique and tailored landing page.

  The caveat is, it will also require a developer to maintain the code and fix any bugs that may arise in the future.

  Need to change text? Publish a blog? You will need a developer. You will most likely have to pay the developer, as well.

• Use a no-code tool like Webflow, Wix, etc or use AI to create a generic page.

  The justification is that this will allow you to quickly and easily create a landing page without the need for a developer.

  The caveat is that you may not have as much control over the design and functionality of the landing page as you would with a custom-built one. However, you will save time and money in the long run by not having to maintain code.

What choice would you make?

5. Software gets complex.

As you push the software into production and start getting users that are relying on it, the software immediately becomes more complex. Suddenly, the developer can not just drop the database, change the API response format, or refactor the code without considering the impact on the users.

This implies that every step, feature or decision has to be take in tandem with the users (even though they are not in the same room).

And, of course, with increased complexity, comes increased cost (in terms of time, mental cost and money).

Want to migrate a database? Developer plans for a downtime.

Want to add a button that twerks for the user? What if it breaks the user experience?

6. A contractor is not an employee.

This is a common mistake that I have seen some founders make.

They hire a contractor to build their product and then expect them to be available at all times, to be responsive to every message, to be proactive in suggesting features, etc.

Unless they have a stake in the company, they are not going to be as invested in the success of the product as an employee would be. They are doing a job and they will do it to the best of their ability, but they are not going to be as passionate about the product as an employee would be.

More to the above, I have seen cases where the contactor literally has the IP of the company in their hands that the founders do not have access to.

This is such a risky situation for both parties if there’s no proper documentation and handover process in place.

7. Understand how the parts feed into each other.

I’m not saying that you need to pick up coding, but you need to understand how the different parts of the product fit together. For example, what is a user interface? Where does the data get stored?

Knowing the basics of how software works will help you communicate better with your technical team and also help you make informed decisions about your product.

For example, if the developer tells you that they are still changing the database schema, you ought to understand what a database schema is and why it is important.

This might be a hot take but I genuinely think that non-technical founders should have an iota of technical knowledge. It pays off in the long run.

8. Documentation, diagrams and written notes will save time.

Keeping documents such as flow charts, wireframes, etc will help you communicate your ideas to the technical team and also help you understand the product better.

For example, if you want to add a new feature to your product, a simple write up about what the feature is, and how it should ideally work (no, it does not have to be technical) will immensely help the developer of the software to better understand the end goal.

9. Your developer needs time to code.

I have met some founders that want updates every single minutes (I’m exaggering but you get the point). Personally, I sometimes need space (spatial or mental) to perform deep technical work. For example, hunting down a bug, a refactor or new feature. Constantly having to context switch between messaging and programming is detrimental to my productivity.

This does not mean that the developer should not be offering updates or be responsive to messages, but it does mean that they need to have some uninterrupted time to focus on the work.

For example, at the end of each working session, I send out messages about where I am with the work, next steps and, if any, blockers. This way, the founder is always in the loop without having to constantly check in on the developer.

10. Keep a software bill of quantities.

This could be a simple document that lists all the features of your product, the technologies used, the third party integrations needed, etc.

Ask the developer to update this document every time a new feature is added or a new technology is used.

This immensely helps in case, for example, you need to switch developers or if you need to hire an employee to take over the product.

My most recent experience was with a founder that could not exactly tell what OTP service provider was being used in the product. To make it worse, the hosted codebase (Github) was different from what was in production.

Such a nightmare to deal with.

In conclusion, there are downsides and upsides to being a non-technical founder. Know your strengths and gaps and try to fill them in with the right people or processes.