Tips for Building Software Products as a Non-Technical Founder
This week’s topic addresses an issue I continue to run into with founders I advise, whether within the HVL family, external investments, or other founder conversations.
It’s a particularly thorny issue for non-technical founders: managing your first technical partner when building software. The technical partner, in this case, can be your first hire, an outsourced firm, or a consultant/freelancer.
There is a fear and trepidation around managing and dealing with developers that can be frustrating and sometimes paralyzing to non-technical founders. I hope these tips can help you improve your chances of building great software, even if you’re non-technical.
I won’t dwell much on the hiring process other than to recommend doing as many of these things as possible: check references extensively, get someone technical and proven to help you validate technical skillset, give a skills test — lots of options to use here — and spend time with your potential partner to be sure communication patterns match and the person pays attention to detail.
One primary risk for non-technical founders is successfully building a well-designed, well-architected initial “take to market” product. It’s the first area investors want derisked.
Unfortunately, horror stories are painful and plentiful, ranging from having absolutely nothing to show for months of work and hundreds of thousands of dollars, to software so buggy it’s unusable. I was a software developer in my earlier life. I am still subject to this risk when I don’t pay the proper attention and apply some of the things I’ll discuss here to product development, especially with outsourced teams.
Build Visuals and Be Clear on What You Want As Much as Possible
You can’t outsource the vision. You can’t outsource your role as the first product owner and manager. And you can’t be vague about what you want to do. If you do these things, what you get back may differ significantly from what you intended to build.
In describing your product for your developers, you need to go beyond surface descriptions of features. Capture the vision in writing, draw outcomes on a whiteboard and discuss them together. Be all in. Don’t simply write a few paragraphs about what you want to build and expect great results.
I’m not much of a designer, but in the early days of building some of my software products using other developers, I drew out exactly what the workflow, layout, and user interactions would look like on a piece of paper. When products like Balsamiq appeared on the scene, I would use them to draw wireframes to share with developers. It is a critical first step to capture your vision on wireframes (or paper if you’re that non-technical) and iterate through versions of it.
Use a Project Tracking Software
Project tools like Trello, Jira, and others allow total transparency between you and your developer on what needs to get done, what is in progress, and what is completed. It helps you have full clarity, and each project task should be explicit about what a finished task will look like and in what timeline. If you’re outsourcing your project to a dev shop, they need to give you access to the project management tool for your project. Not giving you access should be a huge red flag. Visibility into what your developers are turning into a finished product is a key requirement for speed and success. The tasks in your project management tool are your raw materials. Not having access will be similar to being a restaurant owner who doesn’t see which ingredients the chef and kitchen staff are turning into meals.
Use a Cloud First Code Repository That Gives You Visibility into Work Done
Do not be scared of all the crazy stuff we call software. You don’t need to be an expert to get an idea of what work is getting done. A code repository like GitHub is a great way to get familiar with the raw materials that turn into your finished product. Even though you’re not a technical founder, you should familiarize yourself with your software in the early days and learn enough to grasp the work being done. As a founder, you should be familiar with and see the work output of your team. Think about the code repository as a form of work output. Just like you would want to see Google Analytics from your marketing efforts or customer feedback surveys, you should be viewing and understanding the work done by your technical partner. This is why someone with the right communication skills is important. Implement whatever variation of the below tips to give you visibility:
Ask that every task be broken into smaller chunks of development work that will take less than a week to complete.
Request almost daily code submission into the repository so you can stay up-to-date. Not more than 2 days of work.
Unfinished tickets or sub-tickets are tagged as work in progress to allow visibility into what is being worked on.
Each pull request should be tagged with the appropriate ticket it is associated with.
Many resources are available online to help a non-technical person get familiar with GitHub. I will recommend reading some of these to better understand how it works.
Have Frequent Conversations
I recommend a daily stand-up with your developers. A daily standup should be quick and focus on blockers on current work you can help clear out of the way. Being a part of stand-ups with the tech team is particularly important for non-technical founders to familiarize themselves with the software development process. The daily updates will be more digestible than trying to understand weekly or monthly updates. Treat these meetings as a part of your learning process. Having a stand-up daily may be challenging, but try to have them as frequently as possible.
In addition to stand-ups, schedule demo meetings where a feature still in progress is demonstrated for you before release. Demo meetings are typically longer meetings than stand-ups but less frequent, preferably weekly.
Your primary goals here are two things: Does it capture what you want to build? What did you feel as a first time user? “Heck yeah, nailed it?” Or “Hmm, not sure about what’s happening.”
What you sense is likely what your user’s first impression will be.
Record your initial impressions and experience with each feature before it’s released, and capture your level of ease or confusion. Re-evaluate your experience with the whole product in light of the new releases. Observe how you feel – do you get lost or confused anywhere? This is how a new user will feel too. Replay that to your developers. Don’t delegate this in the early days. It’s easy to get so familiar with the product over time that once you know the happy path, you dismiss these initial product experiences. But remember that your users will not give you the benefit of the doubt when they face confusion with features. Here is a scenario where your non-technical background becomes an advantage. Without the investment or knowledge of the feature developer, you can better mimic the customer experience when using a feature. Use this to strengthen your product in collaboration with your technical partner. Be the voice of the customer to your team.
Treat Them Like Valuable Team Members
Your first developer or dev team is a key part of your success. Treat them as such. This point is especially important when using outsourced and remote teams. Treat your founding developers with dignity and respect. Sell the vision to them as hard as you sell it to yourself and investors, and let them be proud of what you’re building, not just some hired hands. Acknowledge their work and get to know them personally. Know what excites them. Celebrate personal events in their lives and let them know you care.
These tips will set you up for success, so don’t let your lack of technical skills prevent you from building the product you want to see in the world. Let me know your thoughts here or on Twitter (@sotulana).