5 Things Every Non-Technical Founder Must Know

5 Things Every Non-Technical Founder Must Know
This post was published on the now-closed HuffPost Contributor platform. Contributors control their own work and posted freely to our site. If you need to flag this entry as abusive, send us an email.

Are you a non-technical founder building a product in the tech space? You’re not alone! There are tons just like you who’ve successfully built some of the most widely used apps today.

Take for instance AirBnB. The company’s founders don’t have an engineering background. But they did many things right to ensure product success.

Here are some of those things that successful non-technical founders focus on to deliver a better product.

Spend on product development, not marketing

A fantastic product with no marketing budget is far better than a crappy product with over a million dollars in marketing. Customers can see through bad products and experiences.

No amount of advertising or promotion can engage a customer with your product if it doesn’t live up to its promise. Wantrepreneurs want to build a product on the cheap, keeping a larger share towards marketing.

By looking for the cheapest deal in product development, they’re hurting their business directly and eventually shut shop, often making excuses on why their product didn’t work.

Successful non-technical founders know that product is key. If there’s no good a product to experience, they wouldn’t get the customer’s organic word of mouth – the single biggest marketing channel for apps.

Focus on time to value

Time to value, simply put, is the amount of time it takes your users to realize the core value of your product.

The goal of the engineering team along with the user experience team while building the product should be to get users to experience the core value as soon as possible.

Every product across the B2C or B2B spectrum will have their own onboarding process which can be from simple in-app wizard to a complex data integration or product configuration type. Measure this in hours and days rather than weeks depending on the complexity of your product.

Define what the value would mean to you ― higher conversions, increased revenue, quicker time to transaction, etc. Based on these metrics, you ensure that your product design addresses them at every stage of the customer touch point that is important to you.

Strong contract

When starting the relationship with an outsourced product development partner, ensure that the outsourced developer and yourself or your team is completely aligned with your vision and the product specifications.

Ensure that your expectations have been understood well by the developer, which should also be exhibited in the proposal or the contract that you sign with them apart from the conversations you’d have with them. The contract also should clearly state the deliverables along with the timelines for the tasks.

The contract should highlight and address the intellectual property rights, source code ownership and handover, project credits, etc. If everything is well-documented, you’d be in a better position to negotiate when things go wrong.

Infrastructure can be a big cost

One of the biggest components that add up to the cost of building a mobile app isn’t really the features but the infrastructure required to build them. For instance, third-party application programming interfaces (APIs) are out of the control of the developer’s environment and can really raise the costs dramatically.

Then, there is data storage (in-app or backend database) and the method it would use depending on the complexities can have a greater impact.

If you anticipate good traction for your application, the scalability has to be engineered at the foundation level ― not in the app but at the backend. Based on the complexities of your application, the intensity of these greatly varies, thereby impacting the costs.

These are some of the most crucial elements in your app requiring an expert hand to work them.

There’s no bug-free app

Can a human being write bug-free applications? The technical answer is yes. The practical answer, on the other hand, is not so much. The reason behind this is that it’s just not economically viable, unless you’re building a life- or mission-critical application.

A piece of software or an application does not run in isolation on a perfect device or system. It has dependencies of the platform that are out of its control and the existence of libraries makes it even more complex.

If you want your application to be bug free, then you need to also ensure that every library you utilize is also completely bug free ― which is simply possible when you’re relying on a third-party for this.

Speaking of third-party, even the slightest of complexities in an application triggers the integration of a third-party application program interface― again, an external reliance with no control.

Popular in the Community

Close

What's Hot