What entrepreneurs need to know before building a tech product

Have an idea for an app, software or tech product?

Here is a checklist for all entrepreneurs that want to avoid failure when launching a tech product. This checklist will be essential in guiding your strategy – and will help you to determine a budget.

This in turn can help determine at what point you might use crowdfunding as a minimum viable product (MVP) for testing your product, or how much you will need to raise in order to make your idea a reality, whether that is via investment, traditional lending, or crowdfunding for example.

If you are still questioning why you need to consider a software strategy, please note the key software statistics below:

31% of software projects will be cancelled before they are completed. (No plan or under-estimated the cost and personal time investment)
53% of software projects will cost twice as much as their original estimates. (There goes the sales and marketing budget)
Only 30% of software projects will succeed. (They had a plan!)

There are many types of software development approaches in the market. Each item addressed in this article needs to be considered to reduce your risk profile of software failure in the hands of your staffor customers.

The statistic I mentioned before about software projects costing twice their original baseline estimate leads to the question……Should I even pursue my software project in the first instance?

Answer to that is you need a quote or estimate.

You need to estimate what the project could cost along with possible contingency costs factored in also. (Contingency is factored in to cater for change of software design or delays).

Questions you need to ask yourself before starting the project:

How long is your forecasted schedule or delivery date?
Are you building the software in-house or outsourcing?
What specific skill-set is required?
How many resources do require?
What are your personal requirements for the project?
What are your design and build costs?
What are your testing costs? (Your testing costs will depend on your software requirements and design)
What are your software hosting costs?
What are your post go-live support costs?
What mobile devices, web browsers, screen sizes and operations systems need to be factored into your design? (This is extremely important to know upfront avoid unforeseen costs down the track)
Do you need to cater for the visually or hearing impaired with your software?
Are you going to manage the project yourself or hire someone?
Most importantly, has someone with the adequate experience reviewed the estimate to verify if it is realistic?

Depending on your budget, there might need to be a trade-off. If you have budget constraints maybe some functionality might need to be delayed for future markets release. Before you have moved into deep planning, here you can make important decisions before spending any significant amount of money. E.g. maybe some particular devices and web browsers can be catered for in future software releases. Maybe just prioritise the most popular devices or browsers in the market place at the moment to begin with.

How do entrepreneurs estimate a software project?

The below diagram is a high level example estimate for a software project. This could be for a desktop or smartphone application. The estimate assumes the software will be developed in small 2 week intervals for particular functionality over 18-20 weeks. Costing rates per hour will depend on the resources and their geographical location you choose for your project.

If you want to access the template for your own needs, please access via the link the below:

http://bit.ly/1PQcIZt

Feel free to modify or play around with the numbers depending on your circumstances. This is a simple guide to get you started.

Please note: The above development approach will assume ongoing user testing and exposure of the software to select end users. This will allow early feedback to be incorporated into your software.

Now let’s assume you have given the project a green light.

How are you going to prove the software is fit for purpose prior to market launch? What are the key elements you need to consider that could cause your software to fail?

This is where a testing strategy will assist and address that requirement. A test strategy is also useful to address potential missing elements in your software design. This can save you considerable cost before the project is in full swing.

A software testing strategy is there to verify the specific items you addressed in your software design work in conjunction with each other prior to market launch. Otherwise left untested can cause catastrophic failure in the hands of users or customers when launched to market.

Below are the quality control checklist items to be considered with your software test strategy:

User Feasibility: Before you begin spending significant effort, time and money on your idea. Is it feasible and addressing market needs? You can check this by interviewing users personally or by utilising external companies that can gather this user feedback on your behalf, or testing your idea using crowdfunding as a Minimum Viable Product (MVP)
Test Estimate: Will address each of the below dot points in isolation.
Test Strategy/Approach: Focuses on how the quality control processes will be planned and executed through the software development lifecycle prior to market launch.
Business Requirements and software design review: Testing or subject matter experts can review the software requirements or design to locate potential defects before any software development takes place. Defects are cheaper and quicker to fix at this stage.
Component Testing: If you have a team of several developers who is writing code for an application. This testing involves each developer confirming their particular piece of software is fit for purpose prior to merging with the overall software.
System Testing: This focuses on testing the standalone software. E.g. packaged desktop software like Microsoft Excel. If the software interacts with another piece of software, here that simulation needs to be tested also.
Cross Browser Testing: Due to the variety of Chrome, Internet Explorer, Safari and Firefox browser versions on the market, your software may behave differently in each one. This must be tested and catered for in the software design and development phase. It is very important to point out here that the most popular browsers need to be tested, not necessarily all versions. This all depends on what your customer base is using.
Desktop Operation System Testing: This testing focuses on the same items as cross browser testing, but focuses on the different operation system versions for your software. E.g. Windows and MAC operation systems. Again, you should only test based on what your customers are or could be using in the future.
Mobile Device Testing: Due to the explosive growth of mobile devices especially in the last 10 years has created an ecosystem of different mobile operation systems and web browsers. This is specific to mobile technology. This includes tablets and wearables also. Depending on your customer base you need to identify a strategy that caters for each device. E.g. Your software on an iPhone 6s, Samsung Galaxy smartphone and ASUS Tablet can behave differently on each of those devices for your user base. Internet WiFi, 3G, 4G and even GPRS speeds need to be accounted for.
Location Testing: Due to the different types of internet speeds around the work, some forms of location based testing is required. E.g. how does an application perform in a low speed South America country with your software when compared with a customer from the United States?
Integration Testing: If your software requires an interaction with another software company. Perhaps a billing or banking platform. Under testing conditions you can interact with the other company’s software to confirm if your software or their software may contain defects to be fixed prior to market launch.
Performance or User Volume Simulation Testing: This is to verify how your software and underlying infrastructure will perform when 100, 1000, 10,000 or 100,000+ users log onto your software at once as an example. This also needs to be taken into consideration for other companies you may integrate with.
Security Testing: This testing is there to specifically find any possible security flaws your software. E.g. someone being able to access your customer database and obtain credit card details.
Accessibility Testing: This testing addresses if your software is compliant to support hearing and visually impaired people.
Automation Testing: This testing allows you to simulate the use of software without manual intervention. It allows quick identification of defects prior to market launch.
Regression Testing: This focuses on how previous software versions behave after software enhancements or defects have been applied. We need to ensure the new software update and the previous version operate as expected.
Exploratory Testing: This phase allows a user under testing conditions to search for defects without any pre-determined plan. Basically the tester can use the software as they please for a period of time.
Usability Testing: This is a continuous activity of real users in the market testing your software during prototyping phase, pre-launch phase and post launch phase to evaluate if improvements are required. This can be in the form direct observation, audio and video recordings.
User Acceptance Testing: This is when business or actual users verify if the software addresses the original business case or requirements prior to launch. Usually identified as the final stage of testing.
Beta Testing: This is when software is released to market, but only accessible by a particular control group. Other formats also include making software downloadable for free during a period of time. The primary outcome of this testing is to gather any last user feedback prior to full market launch.
Operational Readiness Testing: This is when the support staff simulate deploying the software prior to formal market launch. The purpose is to identify any implementation issues that could delay the upcoming live market software deployment.
Operational Support Testing: This testing is specifically focused on addressing any critical defects that could be found upon live software deployment or for a set period post that time. Sometimes this can be described as a warranty period.

There are more disciplines, but these are the core items that can mitigate the risk for entrepreneurs of software failure in the marketplace.

Remember, these are guidelines. They can be incorporated into any software development approach.

I would love to hear your opinions, questions or subjects you wish for me to cover.

Please post your feedback to me via the discussion boards below or visit my website at www.mikehamilton.com.au.

Thank you and signing off.

Michael Hamilton