Introduction
Many start-up and business books recommend building a great team first and then working on a fast/failure model of product development.
In the “Real World,” that won’t work.
You won’t have the start-up capital to hire the team you need or the time to do it.
Maybe the “team first” model works in Silicon Valley, where people will often work initially for free (called “sweat equity”) and entrepreneurs with a good deck get funded for millions of dollars. However, back here in the “Real World,” you need to have at least something exciting and dynamic to show as a product, before anyone sane is going to consider leaving Facebook or Google or their Academic cushion to come and work for you and your little pipedream.
So, by all means, start conversations with the folks you would like to have on your team in due course, but immediately on Day 1 of your business starting, get going on building an initial version of your product. While building your team is obviously key to turning your idea into a scalable business, it’s much better to have something concrete to show people. Even if it’s just some iterations of a “Wireframe” and initial MVP.
A Wireframe is a sketched out “Mock-up” of the key pages on each screen of your software. They clearly show the buttons, options, actions, and visual representation that the end user will see. They are super helpful both for your developers to use as a template for the first build and for you as the designer. It helps you think critically about the user workflow and how the users will interact with the technology you are building. Your solution can have all the amazing functionality in the world, but if it’s hard for clients to use or doesn’t make sense to them or the industry, then you are wasting your time and your money.
By all means, draft a Wireframe if you yourself are able to. These are easy to complete and great for visualizing your vision to developers. Ask a tech friend to help you if needs be. Not the developer of your product (you need to be able to fire them). There are tons of free Wireframe websites and apps available online to get you started (or visit my website shanebrett.io).
An MVP is a Minimum Viable Product, that is, developing an initial product with the minimum features required in it to be of use to an initial client and user. The budget for building a good MVP you can demo to a client should be below $30,000.
Larger companies pay millions to develop enterprise software. You don’t have to. You are fast and nibble. You know your industry segment. You know the leading players, and most importantly, you know the pain they are experiencing. You can build something in a few months that will start providing the solution.
Once the business is set up, you should complete the following product development steps:
1. Pulling together the initial funds for your MVP—This will be either the start-up funding you have saved, perhaps a government grant, or a loan from a bank or third party. I don’t recommend taking family money. Not unless you want every future Christmas/Thanksgiving dinner to (probably) be a very tense affair.
2. Designing the MVP—Initial research with target market could just be yourself and a few trusted peers.
3. Finalizing your MVP development—You should aim to complete two rounds of product development. This is key. The initial MVP you receive and then the updated MVP will enable you to get detailed feedback on what works and what needs to be added. Then, when you have incorporated them into your updated MVP, you should be ready to show it to potential customers.
Getting Started on your Minimum Viable Product (MVP)
You will need to find the right person or company to build version 1.0. The secret here is to ask around. Ask your friends in software. Mine your professional network for recommendation and then look for references from a couple of developers. If you know any other technology entrepreneurs, they should be at the top of your list.
This first MVP will be a long way from the product you deploy with your first client, but it’s another key first step. Forget about the ideal end solution right now and instead focus on the core key benefits you want to provide your client.
You are aiming to have something good and that is ready to get people excited for under thirty thousand dollars. Ideally, closer to twenty thousand dollars if possible. In this age of open source code and fast product development, this should be achievable.
Obviously, you have to make sure in black and white that the intellectual property belongs to your company and not the product developer. Make sure you can see that clearly in any contract or document before giving the green light and paying an initial mobilization fee.
Many product developers will look for half the money upfront. That’s ok, but it’s not ideal for you. If possible, negotiate hard for one third upfront, one third on initial delivery, and the final third after your feedback and changes have been added to the MVP. This will give you more leverage and power in the development process.
Also, make it clear to the developers that this is just an initial piece of work and if they do a good job and you establish a working relationship, then there will be a lot of follow on work as part of a long term business partnership.
Regardless of how the commercials are structured, you must make sure the deal is agreed on a flat fee basis––not on a per day or with any variable element. You can’t afford that, and it will kill your cash flow quickly. If the project is for a set fee, then the developers will be keen to deliver it quickly, get your approval, finalize any updates, and move onto their next project.
If at all possible––and this goes for all aspects of your business––try and meet the developer/development company face to face once. Of course this may not be easy, given geographical locations and the recent pandemic, but business flows so much smoother when you have met in person before.
As the product evolves, you will need to expand the product pages of your first deck to provide a clear, illustrated walkthrough of our new product and the key features it will contain.
Using MoSCoW Prioritization
To decide on what needs to go into this first iteration of your MVP, try using the MoSCoW prioritization methodology. MoSCoW stands for must have, should have, could have, and won’t have. Every idea you have had in relation to the new technology needs to be dropped into one of these buckets.
To do this, think carefully and critically about your new software product and what needs to go in there right now to catch the interest of your first client.
“Must have”—are critical requirements. There is no way around these requirements. They are crucial to the product’s success. It is essential that these pieces of functionality are ready to use in your product right from Day 1. Without them in there from the get-go, no one will buy the product because it won’t solve the problem it’s meant to address. These items must go into your first MVP right now and should be reflected in any Wireframe mock-up immediately.
“Should have”—are important but not necessary. Ideally, they would be in the product if time and money allowed. Often, they can be time dependent, that is, a nice report or new drop-down menu that should definitely be in there but due to your delivery deadline, will have to wait till the next build. If you know your industry well, you will probably spend more time considering what “Should” be in there versus what you know “Must” be in your Day 1 product.
“Could have”—are desirable but not necessary. These developments could improve the user experience and make your clients happier and probably would not cost much in additional time or budget (e.g., more options in a particular field). These are up for discussion with your development team if time and resources permit. “Could haves” have a question mark over them with the development team, as they need to be validated as to whether or not they are easy to build.
“Won’t have”—are not going to be built right now. What could this be? I hear you say. Often this will be something that is just not possible at the current phase of development (and often for the foreseeable future). You know clients will want it further down the line and it may very well be required eventually, but right now, it’s beyond the scope of your budget and timetable. For example, an advanced reporting module may be a certain requirement for you to successfully deploy the solution globally at a large company. The problem is that you could spend a couple of million dollars on this enhancement alone, so it will have to wait till later. Any questions from prospects about these kinds of requirements should be met with: “It’s one of the items we are considering for our future Product Roadmap.”
Most decent MVPs will consist of a large number of Must haves, a few important nice to have Should haves, and potentially a couple of Could haves, if your development team think they are easy to deploy.
There is a lot of more interesting information about the MoSCoW
prioritization method of software development available online.
Product Development Document
Before commissioning the MVP, you will need to prepare a “Product Development Document” for the developers. This document will scope out the details of what is required on each screen, how the user will interact with each, and how they will relate to each other. This walk-through document must cover each of the main screens on the product. It will be the guiding light of development, so document everything carefully.
This document should be structured as follows:
• An introduction explaining the business case, for example, this software solution will be used by the health and safety department of lunar transport companies to manage passenger health readiness for travel into orbit.
• Explain each screen in the application. A wireframe screen shot of each is ideal. Then, an explanation below the picture outlining what each piece of functionality (e.g., Drop down, Button, Click-box, etc.) should do.
• Explain how they will relate to each other, for example, if I click this button at the top of screen X, it takes me to screen Y.
• Outline how the user is expected to interact with the software, for example, a typical user will review the data in screen X and click a “checkbox when complete” box. This will then take them to Screen Y where they can run a simple report.
If you are trying to build a new product for an industry or area that you have little experience in, this is where you will come unstuck. Your requirements will be mere guesses. You won’t know what people will buy, never mind what will sell. The key “Must haves” and “Should haves” won’t be correct. You will have built the wrong MVP and then you are out of cash.
Managing the Development Cycle
This is probably the first time you have managed a software development process and it may be particularly fraught, as you are likely using your own hard-earned cash, so you need to end up with something good.
Developers can be hard to manage. Treat this initial development process as good practice for managing your team later, as the company expands.
The best approach is one of constructive collaboration. Jumping up and down doesn’t work (as you will find out). Emphasize the long-term relationship you are keen to build. Be friendly and polite. Use external deadlines as a driver to keep things on track (i.e., I am demoing this at a conference on the 15th of next month; the first prospect wants to see it in six weeks and so on).
Send them the wireframe and the Product Development Document you have drafted. Give them a day or two to review it and then have a detailed call walking through each part of the document and answering any questions they will have (developers always have loads). Feel free to grab screenshots of other software layouts that you like and send it to them for guidance.
Agree to a follow-on call each Friday (or Monday) to agree the work schedule and for them to update you on what has been built (ideally showing you) and to decide on the next stage of the product development. This meeting just needs to be twenty minutes. Keep it brief and constructive.
Finalizing a Good MVP
It’s going to take two rounds of development (minimum) to get your MVP close to what you envisaged.
The first delivery will be the initial draft. What the developers have understood from your Product Development Document. They should be able to deliver a Version 1.0 of the MVP in six to eight weeks (ideally less).
The commercial agreement with them needs to include this second round of development. Otherwise, it can get awfully expensive and you can be left with a useless product.
When the developers deliver Version 1.0, have them arrange a “Review Meeting” a few days later to walk you through their development and their logic behind each screen. You need to be fully ready for this.
Use the few days in between delivery and the Review Meeting to play with Version 1.0. Try and break it. Take loads of notes and get lots of questions ready. This is your chance to make sure you are happy and ask for any changes (there will be plenty).
Carefully reconcile what has been delivered to what you requested in the Product Development Document. Note any differences or required changes. Document what you are not happy with and the changes you suggest versus the changes you are insisting upon.
The first development phase will have given you a chance to think about any additional functionality or changes that are required. This second iteration of the MVP is based on your feedback as a Subject Matter Expert in your industry and perhaps suggestions from the first parties who have seen the initial wireframe mock-up.
Your satisfaction with the second iteration of your MVP should be wholly driven by what you know you can sell in your industry. Is this version 2.0 enticing enough to be of interest to potential prospects? Can you comfortably demo the MVP to a room full of strangers?
Demoing software is an art in itself and one that only comes after months (years!) of experience. (See Chapter 6.) Demoing can be hard to get right until you do it. Get started as soon as possible.
Start Looking for Feedback
Now that you have spent your hard-earned cash, hopefully you have something exciting to show for it. It won’t be perfect and will be a long way from your ideal product, but it should be dynamic enough to demonstrate the flavor and potential of your idea.
You need to start showing people immediately. Don’t be shy here. Invite plenty of friends and industry colleagues out for coffee and show them what you have built. Ask them for positive thoughts and constructive feedback. Ask them what they look for when they are buying software.
Critically ask them the kind of questions they would ask potential vendors. Any feedback on the product is good if it is genuine. Make copious notes on the questions they ask you and the ones they would ask in a software demo. Think carefully about detailed answers to each. This can save your bacon when you are demoing the software for real in a room full of potential commercial prospects.
Lastly, ask them if anyone in their network would be interested in seeing it? This is important. The people your network know can often end up being your first clients. Make it clear at this stage that you want to meet them more for market research than sales and their feedback would be invaluable for future development.
No one likes the hard sell, but everyone likes to see nifty new technology that can make their lives easier. Often these invaluable personal recommendations can be where your first business client will emerge from.
From here, you will start to contact these warm introductions through your friends, peers, and industry network. You can have the first introductory meetings with potential clients. Emphasize that these are for research and feedback only. At this stage, you are in exploratory talks with the first potential clients and the aim here is to build a realistic gap analysis of what you have in your MVP right now versus what a real client would need to buy and deploy your product.
Your friends are no good anymore. You need to get the MVP in front of real potentially paying customers. Friends will tell you what you have built is great regardless. What you need is cold feedback in the hard light of day. It is better to receive this constructive criticism and feedback right now, than spend any more money enhancing your MVP in the wrong direction, and in a way, that is simply not suitable for your target clients.
Once you have had some initial discussions on the MVP with your first few potential customers, it is time to incorporate this feedback into devising a proper software demo plan, while building out an underlying business development strategy and finding the right team to drive it.
Chapter Summary
• Identify a suitable product developer.
• Apply MoSCoW prioritization to your idea.
• Develop a detailed Product Development Document.
• Manage the development cycle closely.
• Nail down the best version of the MVP possible for your budget.
• Start showing it to friendly folks and think about their feedback.
• Begin contacting warm leads in the industry for more formal demos.
• Build an initial “gap analysis” of product features you are missing based on first demos.