VReel.co is a platform for the sharing of drone footage — although we’re not pushing the boundaries of AI, machine learning or VR, for me, we might as well be, considering I don’t know my java from my jQuery!
My technical competence stretches as far as being able to (badly) build a WordPress website (see https://vreel.co for our announcement site). This two-page website took me the better part of a week to struggle through, and it still doesn’t look and act as I want!
So how did I build a working product and get to the point of launching a tech company? Here are the five most important lessons that I have taken away from my experience.
1. Find a Great Development Partner and be Transparent with Them
Check references, have Skype meetings and even fly to meet them if it helps your decision-making process. It’s important to feel comfortable with being able to communicate with your developers because there will be a lot of ‘stupid’ questions from you throughout the process. Often, the developers that are structured and assertive in initial meetings are going to be good. Be upfront with them about your lack of technical expertise and be very clear about your vision. Write a product requirements document that describes everything you want the product to do, and then some — leave out no detail. Have a structured schedule for meetings and progress updates. We set 5-minute daily update meetings and a longer retrospective meeting for a progress report at the end of each week. We met on Skype.
Outsourcing development can seem like a terrifying concept. Finding a company to take care of building your ‘baby’ that you trust to do a good job and realise your vision, whilst yourself not understanding anything along the way is not for the faint of heart. Being transparent at the beginning about your lack of technical know-how and expertise is going to dramatically smooth the process. Many companies will immediately not want to work with you, others will still be interested. It’s your task to discover which one is going to be a good fit.
2. Compromise — on the right things!
With a lack of technical knowledge, you may overestimate what can be achieved within your time frame or budget. If you need to cut out features or functionality to come in on time and budget, then make sure you take away parts that won’t ruin your product. During the development process, we thought of our product as an MVP (minimal viable product). However, an MVP doesn’t mean that you have to compromise on having a great product. We’ve cut out some features and functionality, but not the ones that will cripple the product or make it less attractive at launch. Of course, these features and functionality are planned to be implemented after launch for version 2.
Remember, “if you’re not embarrassed by the first version of your product, you’ve launched too late”.
3. Be Prepared & Patient
When you are developing a product and you have zero technical ability, it’s almost impossible to know how long things should take, how many resources need to be attributed in achieving each milestone and what problems will be encountered along the way. It’s important to have a clear structure of the project’s technical requirements from your developers. Utilise project management tools such as Jira to visualise sprints, key components that need developing and to see the overall progress of your platform. Don’t be afraid to say to your developers “I see that ‘component x’ is being built as part of this sprint, can you explain the work that will go into this? I’d like to understand this component so I can manage my expectations of the timeline for this deliverable”. This will help minimise unwanted surprises and make sure you feel in the loop with the development side of the project. Even with these solid workflows and structure implemented there is going to be road bumps and hurdles to overcome along the way, be prepared to be patient as bugs arise and need to be squashed. It’s part of the process, you may even be testing your product yourself, in this case, report any bugs that you find early on and make sure they are added to the list of tasks in the project management tool.
4. Test Your Model and Assumptions Ahead of Time.
Meet with potential clients/partners/users — pitch your idea, take feedback, listen to the feedback, implement the feedback into the product and your strategy. Tell them the assumptions you’ve made, test this with how they currently do business, see how open they are to your new model and find out how much they would be willing to pay for it!
For example, we made the assumption that pilot contributors would like to earn a revenue share based on their level of contribution (instead of a pay per download model). Reaching out to a large group of pilots and asking them how they felt about this model helped us to confirm that there was enough positive feedback to launch the product with this payout scheme implemented.
However, an assumption that we had proven wrong was when we met with ad agency execs — we had assumed that media buying would be more attractive to them on a subscription-based model, which would bring them value. It turns out that expense is not their biggest concern. However, the time taken to find the correct clips is a big concern of theirs. Therefore, we implemented an option for the one-off purchase of clips outside of a subscription membership and made sure to develop our user experience for search and video discovery functionality.
5. Find a Great Partner — I didn’t do it alone!
Having a great business partner to balance out and compliment my attributes was hugely important for the successful execution.
Emelie is tenacious, smart and annoyingly productive. She took responsibility for all of the business side of things: pitch decks, financial projections, company registration and all of the admin to ensure that we won’t break any tax laws. Plus she gave extra input and ideas for the product. Without her, there would have been no chance that I could have executed all of this as well as manage the product development! Of course, like any small business, we both helped out with each other’s responsibilities. But it’s great to know that some things are your responsibility while others are not.
We interviewed candidates for a technical co-founder role in the early days, and if you’re going it alone I would definitely recommend doing this. For us, we didn’t find the right person and that was okay. A little bit of self-belief, a lot of hard work and a moderate dose of learning on the go made it possible for us to get to where we are now.
Obviously, there are more things to consider than just five, key points and everyone’s experiences will be different. But I hope that these will help ease your process.