Working out of 1871, the world’s #1 technology incubator, has afforded us the opportunity to be immersed in Chicago’s startup ecosystem consisting of over 500 startups. These companies span the startup spectrum, from concept to revenue positive and looking for an exit. One common question facing all these companies is how to best leverage technology to take a product to market or differentiate.
Often times, we are approached by business savvy founders to help them take a product to market. These individuals are often subject matter experts in the area they are trying to disrupt, and, also just as often, on the opposite end of the spectrum when it comes to their technology savviness. This often leads us to the following conundrum: ‘To engage or not to engage’ in an official capacity.
First and foremost, as a technology partner, we often have to weigh the risk versus reward of taking on a client engagement. While some might think we are crazy for turning down potential revenue, we think hard and long before engaging with a startup client. We want to ensure they are easily able to articulate the features of the product they want to take to market and have the business and technology team (or skillsets) to support the product once live. Without some of these critical safeguards in place, the startup is setting themselves up for failure in the long run. This in turn leads scope creep, incorrect requirements, a product that doesn’t work as intended, and finally founders (and investors) who aren’t happy with the end result.
With this in mind, we wanted to provide startups with some food for thought as they look to identify an engineering partner to help take a MVP to market.
Determining an engineering partner
Application development is a commodity business! Let me repeat, application developers are a dime a dozen! They range from fly by night operators, to boutique development shops, all the way through to enterprise grade development shops that can hold their own against the larger systems integrators of the world like Deloitte, Accenture, or CapGemini.
How do you distinguish between the thousands of development shops available at your disposal? The easiest nut to crack is if they can support your hours of operations with overlap and their communication language and style works for your team. You don’t want business requirements lost in translation or lack of developer availability during critical phases!
Next, determine if your engineering partner has the required resources on staff to meet your project requirements. Often times an engineering partner might try to influence you towards a certain development language or framework given their expertise and current bench of talent. Ask about the pro’s and con’s of one language versus another. For example, you can use React, Flutter, Cardova or a host of other frameworks to build a mobile app. However, what most non-tech savvy folks don’t know is that each framework has its own pro’s and con’s depending on whether you are developing for iOS, Android, or cross platform. Right from the request for proposal (RFP) phase, engage with the solution architect to have them explain the reasoning behind their tech stack choices. You can use these answers as a way to differentiate between service providers.
Third, ensure that the development partner has experience in the industry your solution is going to be serving. Most times engineers just want to start coding without having a full grasp of why they are building a product and how it is supposed to integrate in the current ecosystem. Engineering teams with functional domain experience can be a huge advantage in limiting rework and getting a product to market that functions as intended.
Next, get a better sense on what kind of vendor lock-in you are dealing with. Some development houses will try for lock-in by tying you to a proprietary application development platform. You will often hear claims that these platforms increase speed to market by x amount or leverage the latest state of the art technologies. While some of these aspects might be true, what they aren’t always telling you is you may have to re-write your entire back-end architecture if you wanted to move your product to a new development shop or hosting provider. Unfortunately, this isn’t something that is plug and play. This will require a decent amount of rework which will come with its associated price tag and timeline.
Finally, ensure the development team brings a level of rigor to their design, development, and documentation activities. Not only should every requirement and decision be documented, they should also be traceable during development, testing, and documentation to ensure someone coming in blind can pick up documentation and get themselves up to speed with limited questions of time from the existing team. Most times, especially with external development teams, the projects teams ‘roll-off’ a project and start work with another client. The startup founders must ensure they have the necessary documentation and knowledge transfer plan in place to avoid any disruption to business as usual.
The minimal viable product (MVP) doesn't need all the bells and whistles
So what’s next, now that you have successfully identified the correct engineering partner? Given our past experience, we would say that managing scope creep is critical to having a product delivered on time and functioning in the intended manner.
As the section title says, the MVP doesn’t need all the bells and whistles. What it does need is just enough features to satisfy early customers and provide feedback for future product development. By following an agile delivery approach with your MVP, you can undertake several iterations and show constant improvement. This helps ensure that you are working on a feature set that is critical to the success of your business and at the same time important to your customers.
Failure to follow a MVP approach could lead to severe cost overruns, a poorly functioning product, and even worse a product that never makes it to market due to constant scope changes. Multiple scope changes are also a big fear of application development shops because it also leads to internal cost overruns and delays on their side. Many times, these third parties will put in strict verbiage in contracts around scope creep, design changes, and the impact it will have on cost and timelines. We can’t stress enough the importance of paying close attention to these details!
The App is live! Now what??
If you made it this far in the article, thank you! If your startup journey has made it past identifying a development partner, and building a MVP, congrats on making it two-thirds of the way in your product journey! Unfortunately your tech enabled headaches don’t end here! In fact, some will argue that the biggest technology pain points come after a product is ready and released to market.
In an ideal world, this product would be able to self-sustain with limited human intervention. Again, unfortunately, this is very rarely the case. Once your app is live, you now have to deal with a host of new questions:
How often will the app be updated?
What is the process for prioritizing and working on new features?
What is your disaster recovery plan?
Is your team equipped to handle any technical related questions?
At first glance, these might seem like trivial questions. However in our experience, these are the questions and roadblocks that often hamstring a startup even after the launch of a shiny new product.
How can Aberdeen Advisors help?
We at Aberdeen Advisors, have had the opportunity to play on both sides of taking products to market. As a boutique digital consultancy, we have built products for external clients as well as internal products that we hope to take to market ourselves. These opportunities have afforded us valuable learnings related to the product lifecycle.
These experiences inform and shape our ‘startup accelerator’ offering, where we partner with companies to develop holistic approach to taking products to market. The steps of this approach include, but are not limited to: selecting the right partners, identifying an appropriate tech stack, building a MVP, and finally supporting and innovating on the product once live in the marketplace. We can plug in across one or all phases of the product lifecycle. Please reach out if you would like more information on how we can partner with you to make your product a reality!