Software development for non-technical founders: a blueprint for your journey
In the previous article, we discussed the overview of software development for non-technical founders. Then we looked at the complexities in software development and the pitfalls involved when you overlook them.
In this article, we discuss the high-level blueprint for your journey in developing your product in the right way. First, we start with the overview of our blueprint before discussing each component briefly in the subsequent articles. Also, we discuss some terminologies that you should be aware of when building your ideal development or engineering team.
A high-level overview of the blueprint
Now that we have understood the complexities and pitfalls of software development, it is time to discuss a structured approach to navigate those complexities and get your product developed. We address this using the below blueprint.
Figure 01: A high-level blueprint for developing your product
Our blueprint is to guide you to understand how to approach software development for your product. Also, although we have included a sequential number, you don’t need to follow it that way. Sometimes after finishing step 2 in our blueprint, you may have to return to step 1 to refine your requirements more. Hence, use this strictly as a guide, and adapt to your situation.
You must conduct additional research in each phase, as required. To help you with this, we highlighted some additional reading for each step.
Although the blueprint looks simple, it is extensive, requiring a book on its own to unwrap. However, we tried our best to keep it concise and high-level enough to give you some direction.
Get the requirements right
It is very important to get the right requirements and get them right to keep the software development efficient. However, we recommend an interactive approach to finalizing the requirements. Once you expand your requirements based on your product research and discussing your idea with many potential customers (or other founders), we strongly recommend narrowing down your overall requirements to what you intend for your first release. Usually, this is called Minimum Viable Product (MVP). However, we consider MVB a process rather than a product; hence, we call it your first release (or market-fit release).
Your first release should target anywhere between one and four core features. This feature selection depends on the crux of the problem you are trying to solve and what is important for your customers. The second part of the previous sentence is important since what you perceive as important is often different from what your customers consider important. It is important to get this correct before you start developing your product, or it will be a hard time for you to get people to use your product.
Figure 02: Factors involved in refining the requirements for your initial release
There are many ways to figure out and refine your requirements for the initial release (also, the same technique is applicable for all your subsequent releases). We have provided references to some books at the end of this section to get a deeper understanding.
Shortlisting your initial release requirements
One way is to make a structured problem statement template, discuss with your potential audience, and summarize them according to the template. Alternatively, you can use the problem statement canvas provided by innovation frameworks such as Strategyzer Value Proposition Canvas or the one by Intrapreneur nation. If you use one of the canvas, you need to summarize the problem statement using a simple structure and stick them on the wall.
Then prioritize them according to the urgency you perceive. Then take the first two and discuss with your potential customers over video conferencing or face-to-face meeting. Make sure the people you discuss have such a problem, or it will not be useful.
Record the session with their permission if required. Once you have discussed this with a minimum of 50 (or whatever number you can reach, but a minimum of 25 is necessary for your initial release, you must repeat this process for each new requirement you wish you implement in this future).
After concluding your idea networking, go back to the drawing board and reprioritize according to your discussion with your potential customers. If you have a minimum of two features, you can either move to the next phase or continue this process with two different problem statements to have a minimum of four finalized problem statements to work with.
Build prototypes
We do not recommend developing any software at this stage since your requirements are not ready yet. The purpose of a prototype is to make changes after your discussions with your potential customers. Wireframes are a great way to do that since there are no software engineers involved, and you can do it yourself. We recommend finding a wireframe software such as wireframesketcher (our personal favorite), InVision app, or Proto.
Spend time building quick prototypes of the first problem you are trying to solve. Sketch the workflows involved, and then start designing wireframes for that workflow. Research your direct and indirect competitors for some inspiration (what works and what does not work). Remember, the goal is not to get a perfect wireframe, but instead, your goal is to build a good enough prototype to show to your potential customers and get their feedback.
Designing a perfect prototype without any input from your potential customers make you emotionally attached to it and potentially break your heart when it is not what your customer want. Designing them “good enough” will help you achieve more with lesser time. However, you should pay attention to some of the basic user experience such as navigation, alignments, minimum inputs, and shortest workflows to keep your customers focused on providing their feedback on the functionality rather than wrestling with the user experience.
Once you are satisfied with your ability to let your customers click through the screens without much help from you, you should find your potential customers to test them.
Find potential customers to test your prototype.
It will be ideal if at least 40% of the customers you networked to refine the problem statements volunteer to test your prototype. There is no science on how many users you should test your prototype. Testing with a large set of potential customers makes your product robust even before you develop it. However, not every entrepreneur has the advantage of testing their prototypes with hundreds of potential customers. We recommend a minimum of 50 customers for testing your prototype.
Before you start testing your prototypes, there is a basic checklist of items you must prepare.
Figure 03: The checklist for testing your prototype
Workflows — ways your potential customers interact with your product. It will be more beneficial to develop an effective wireframe and test cases if you design a customer journey map.
Assumptions and constraints — your assumptions about your potential customers and the constraints in which they use your product. Do not write down all assumptions and constraints. Instead, write down five assumptions and constraints based on the priority (or importance).
Test cases and feedback sheets — your workflows are marked with action points (or customer touchpoints) and the expected outcomes. Your expected outcome helps to understand the difference in expectations between your customers and yourself from your product.
Spreadsheet to consolidate all the feedbacks — a simple spreadsheet to summarize all the important feedbacks after each session.
Recording facilities — make sure you have enough space in your video conferencing software or have a recording device with enough space.
Once you are ready to test your prototype (or, perhaps, intimate them right after you designed your prototype and before you start working on the requirements to conduct the prototype testing), send them an email. The email must explain the objective, approach, and anything else you wish to highlight in an informal email that appeals personally to your target audience. Keep the email concise and less than 500 characters. Use services such as Grammarly to figure out the parts your audience might skim through and re-write those parts.
Resource recommendations
Below are some of the resources we recommend for you to help refine your requirements.
Value Proposition Design: How to Create Products and Services Customers Want
Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers
The Right It: Why So Many Ideas Fail and How to Make Sure Yours Succeed
Hooked: How To Build Habit-forming Products
Conclusion
This article discussed the blueprint for you to use and the first component — Get the requirements right. Once you write down all the problem statements you have identified, you need to prioritize them and discuss with your potential customers to shortlist them to a maximum of four useful features for your first release. After that, you need to build “good enough” prototypes using wireframe software to test with your potential customers.
While having a large number of potential customers to help you refine your product helps you release your product right, you must test them with at least 50 potential customers at each phase (requirements and prototypes).