How to Build Your Tech Product as a Non-techie

I’ve worked with hundreds of companies and organisations to help them design, build and support technology and software systems, and I’ve worked with a spectrum of people – from those with almost no technical knowledge to highly competent technology teams, and everyone in between. If you’re unable to speak to technical people on their level, or have no idea how to start working on a technology project, what approach would I recommend you take to ensure your technology project delivers what you need it to, while minimising waste and cost overruns?

  1. Find a technical team you trust. Remember that when the project faces inevitable challenges, it’s important that you have a level of trust in the team you’re working with and a relationship that can withstand the strain of ambitious project schedules. Look for validated customer testimonials, references and referrals, as well as a good personality fit with the people you’ll be working with. Ensure you know the specific people that will work on your project and get confirmation that they will be assigned to the project for its duration (unless exceptional circumstances prevent this – illness, etc.).

    "You buy software, I give you good price."

    “You buy software, I give you good price.”

  2. Value is more important than price. Really good software development is not a commodity and like most things, you get what you pay for. What you save in a low daily rate with one team, you may end up paying ten times over in redevelopment effort, wasted time, incorrect functionality or even complete project failure.
  3. Research and define your idea as much as possible in advance. What’s the business problem you want to solve? What solutions, if any, are out there already and how do they compare to your idea? The tech team can design the technology solution, so focus on thinking through and documenting the business issues in plain English as a first step. Capturing business requirements is a key task in new projects and investing in getting that right first will save a huge amount of time and effort later.
  4. Understand your MVP. The Minimum Viable Product is the most basic version of your product that a customer will pay you for. No matter what size your organisation, the Lean Startup model is an excellent approach to take when developing new technology when there is uncertainty involved, as there almost always is. Ensure that your technical partner understands your MVP, and that it is likely to evolve as you test it and get feedback. The faster you can deliver a prototype, the sooner you can find out if it’s something people will pay for. Avoid any functionality that isn’t absolutely core to the most basic version of your idea, then test it with potential customers and find out if they’re willing to pay for it. If not, try and find out why and let this guide the next iteration of your MVP. The Lean Startup by Eric Ries is a must-read on this subject.

    Just a few more features and I'm ready to start looking for customers.

    “Just a few more features and I can start looking for customers.”

  5. Follow a clearly defined process. Good software development teams will always use a highly process-driven approach to deliver for you. Whether you use an ‘agile’ project approach where short ‘sprints’ of development are delivered every 2-4 weeks for review and approval, or a more traditional ‘waterfall’ approach where everything is defined at the beginning and delivered over time, or a mix of these approaches that enables changes in requirements to be easily integrated into the process, make sure the approach will result in you having maximum visibility and control over what’s going on.
  6. Understand your role. You should take an active and constant interest in progress, without meddling with the team and preventing them from getting on with the job. Don’t allow technical people to bombard you with jargon and words you don’t understand – make sure terminology is explained so you understand the concepts being discussed, but try to strike a balance between seeking explanations and driving the tech guys insane with questions that they’re answering while they could be coding. Another option is to hire a third party technical consultant to act as a second set of eyes to review what’s being delivered. Be warned: sometimes these consultants can be looking for an opportunity to embed their preferred development partner rather than evaluating your existing team – there may even be a kickback in it for them. Be on the lookout for this and make sure they’re giving good, impartial advice and guidance.
  7. Include end-users/customers early. Talk to people. Show them early versions of your product. Get feedback and don’t be insulted if it’s bad, it should help you understand what people want and are willing to pay for. The feedback you get will often surprise you and give you new viewpoints on whether or not further features should be included. Beware though! Don’t ask users what they want in the product unless you’re dealing with very sophisticated users who have a very specific issue you are trying to solve for them. People will often tell you what they think they might want, or what they think you want to hear. Instead, show an early version of the product and get feedback. Always try to get commitment from them to pay if possible – if you can’t, that’s a bad sign. Focus on the features that will add the most value and test these early so you can see if you’re on the right track. Your proof is people using and paying for your product, not saying they like it.
  8. User interface is everything. Where possible, make it beautiful. You could have incredibly sophisticated technology behind the scenes but if it looks shoddy, people will think it’s shoddy. People will often forgive poor/basic functionality in early releases, but if your interface looks terrible or is difficult to use/navigate, people will be much faster to walk away. I’ve seen projects where almost nothing is left in the budget for high quality user interface work – the developers just stick a basic interface on the system. This is a big mistake – developers are almost never designers, so don’t expect them to work miracles on the front-end.

    It ain't beautiful, but... no,  sorry, that's all I got.

    It ain’t beautiful, but… no, sorry, that’s all I got.

Successful software projects are not down to luck – you need to drive your project by understanding the different stages, what you should focus on and demand, and what you can just accept or forgive, knowing that no project is textbook and all projects encounter challenges.

The best software development companies will guide you down the path of following the processes I’ve outlined above (or similar) by default. If they don’t then alarm bells should start ringing. Trust your gut instinct and work with a team that you believe ‘gets’ your project and will be able to deliver it for you.