Leading a technology company as non technical founders presents particular challenges. Chief among these is how to deliver a product.
The answer to this is simple enough, acquire the right talent. But like many simple things, it is easier said than done.
The approach we have taken is to partner with a software development company called hedgehog lab, a global digital product consultancy that has built software for the likes of Microsoft, Santander, Mitsubishi and now our company aidx.
The benefits of this partnership are that it A) Gives us rapid access to technological expertise B) Provides us with the runway to recruit and build our in house team C) Gives us a strategic option for scaling & D) Provides us with the opportunity to learn from a company that has deep experience building technology products.
Below are the twelve lessons that we have learnt finding a technology partner and building our product.
1. Put your customer first
This is cliche not because everyone does it, but because everyone says it. In our experience it is actually relatively rare.
Customer research should be the starting point for anyone looking to build a product, but for non technical founders it is a super power.
If you understand your customer’s problem and can articulate the solution then you will find someone to build it. The clearer you are, the more precise and compelling your idea, the easier it will be.
Sound customer research not only makes sense from a build perspective, but its good business too. The best way to make sure people will buy what you are selling is to understand them.
There are some amazing tools out there to help you do this. Some of our favourite resources are MIT Professor Drazen Prelec’s course Listening to the Customer, Voices into Choices by Christina H Brodie, Sprint by Jake Knapp and everything by IDEO.
2. Be technology agnostic
Resist the lures of deploying ground breaking technology for its own sake.
Do not get dazzled by tech speak or the utopianist visions of the latest blockchain/AI/augmented analytics application.
Focus, instead, on finding the right technology for your customer and for your market. Ask simple questions, will this technology deliver the customer experience that I want?, Does it scale?, Is it affordable?, Will it give us a competitive edge?
3. Devote yourself to learning
Books are your friend, as are articles, blog posts, podcasts, conversations and observation. Learn as much as you can about the technologies that you think might be of use in building your product. Understand core concepts, master the relevant technical language, learn about software development processes and study the latest trends.
This will not only enable you to make smart decisions about what technologies to deploy but it will give you the toolkit necessary to engage with and manage your product and engineering team.
Our starting point for pretty much everything is MIT. The University’s commitment to open learning means that the institution’s expertise is now available to everyone.
Action is most valuable of all. To build is to learn. Make learning an explicit part of your schedule, commit to a constant and conscious process of action and reflection.
4. Remember, the building starts way before the coding
It is tempting to think of building a product as that moment when you write the first line of code. In practice, it starts way before that. Building something is about developing, testing and rolling out a vision; it’s architecture, substance, and logic.
This starts from the day that you pronounce your intent and proceeds as you develop your plans and test your assumptions, through trials, experimentation and talking to your customer.
There are dozens of ways to start figuring out what your product will be, how it will work and what it will look like, that do not involve coding.
Long before we had met with any software developers we had developed customer persona’s, sketched out our product screen by screen using marvel software, developed a process flow for the MVP and taken a view on what we thought would be the optimal technology solution.
5. Minimal viable everything
Read the Lean Startup. Twice. Live by it. Not only will it help you to build your product and grow your company, but it will give you an essential understanding of the core tenants of the methodology that guides the work of most software development companies.
When you come to laying down code, focus on building a minimal viable product. That is, the most pared down version of your product that a. Has enough value that people are willing to pay to use it b. Retains early adopters c. Provides a feedback loop.
Only do this after you have exhausted every other learning tool (see above). Software developers are expensive, so the more you can learn before you engage them the better.
Make this a general philosophy. Build what is necessary to learn, improve and iterate your way towards your product, your team should be commensurate to the task. Do not engage costly expertise until you absolutely have to. When you do keep them focussed on the essentials.
6. Do not engage a software engineering company until you are clear about what you want
When it comes to finding and engaging a software development company, clarity of purpose is critical.
Make sure you have a view of what you want the partnership to accomplish. Not just in terms of product build but in relation to the broader business strategy. Put this in writing, for yourselves and for potential partners.
Our business goals were to get proof of concept and demonstrate traction. Our product goals were to build, measure, learn.
To do this we wanted to build a minimal viable product. We were looking for a software development company that could do this quickly and to specification, that had the capacity to scale, shared our values and would be open to a long-term partnership.
7. Run a rigorous selection process
There is lots of demand for software developers. Costs, capabilities and conditions of engagement vary enormously, with costs generally falling the further east you go from Silicon Valley.
Figuring out who to work with can be difficult. One of the ways to get through this is to run a rigorous process. Develop a precise brief, set clear criteria, seek expert advice and conduct multiple interviews with each potential partner. Where ever possible make a point of meeting people in person.
We relied on an adapted version of the method described in Geoffrey Smarts’ book WHO. Although designed for recruiting individuals there is a-lot of common sense advice that is easily tailored to any selection process.
In addition to producing a selection criteria, we took the time to visualise and write up what our ideal partnership would look like. When we presented it to potential partners we could always tell whether it resonated or not. This proved invaluable in narrowing down who we wanted to work with.
All-in-all we interviewed 17 software development companies from around the world. We sourced them through a mixture of internet searches (Clutch and LinkedIn were helpful here) personal networks and by reaching out to the management of shared work spaces.
Make sure you check references. Talk to people who have worked with the companies you are considering, confirm that they do what they say.
8. Expertise is necessary but not sufficient; culture matters too
Engineering chops are necessary, but not sufficient.
Beyond the ability to code you need to make sure that who ever you work with have culture and values that align with yours.
Ideally, you want whoever you work with to be inspired by and passionate about the product you are building. At a minimum they must have to have the same attitude to work.
We prize honest and rigorous discussion. We use writing alot to clarify our thinking and always make sure we have the space to test our assumptions before we commit to a course of action. When we commit we commit. A team that was either uncomfortable or unskilled in this approach to work would not be a good fit for us.
Your first contact will often be with a business development team, make a point of meeting the actual team that you will be working with.
9. Geography is important
Partner with a software company that is in close proximity to where ever you are. When you are at an early stage and you are still iterating on your basic value proposition the ability to be in the room with the people you are building with is invaluable.
Offshoring is easier further down the line, when there is less need for the back and forth of the creative process
This is why despite speaking to software development companies from around the world we ultimately decided on a company close to home.
If you decide you want to follow this advice, make sure you understand your company’s set up. There are a bunch of outfits out there that maintain business development operations in one market, but actually build your product in another.
10. Be present and engaged
Once you have partnered with someone to build your product do not make the mistake of thinking that you can sit back while it is being built.
No one knows, or is as committed to your product as you are. You are and must remain its driving force.
Moreover things will inevitably evolve as the rubber hits the road and you need to be there to shape the inevitable changes.
Insist on the appointment of a Product Manager to work alongside you. Build in a discovery phase to explore and test your assumptions and design the product development process. Plan to be present throughout the build process. Set times for regular check ins and agree your communication tools ,— Slack, Basecamp and Trello are some of the tools we have used over the years. Make sure you are on all the relevant communications, sprint plannings, stand ups and retrospectives
11. Communicate your vision, be passionate
Passion and vision are essential.
Do not neglect to communicate both, to whomever you partner with. Not only will it inspire them to give their best but if they understand the broader vision it will be easier for them to take initiative, propose improvements and push back when they feel you are off track.
We made a point of presenting our vision on the very first meeting with potential partners. When we did settle on a partner we insisted on a presentation and discussion of the company vision and mission and returned to both throughout the build process.
12. Do not forget the basics
Do not neglect the basics. Respond in a timely fashion, provide quality feedback, be available to answer questions, hold the team to account and be accountable.
A common complaint amongst software developer companies we spoke to was that people they worked with all too often failed to follow these basic protocols. The result is unnecessary delay and frustration, both of which you can ill afford.
Finally, remember that the building never stops. It is easy to fall into the trap of imposing a strictly linear plan on the iterative cycle of the build process.
On paper your path will look something like, “research, prototype, build, launch”, a neat straight line that starts with an idea and ends with a product. In practice you will be engaged in a continual cycle of building, learning and building again. A constant process of iteration, that, if you are very persistent and a little lucky will result in market fit, a position that is temporary too, unless you continue to improve.
It is this latter path that we are on at aidx, and in the months and years to come we will continue to share lessons and insights from our journey.
If you found this article helpful then you may also like Sprinting in Nairobi