I’ve been playing around with the idea of starting my own business since University College, and the ideas have been… diverse! Everything from non-lethal weapon systems, prosthetic limbs, apps, SaaS to t-shirts, books and merchandise. I almost always have a small notebook in my back pocket and a pen in my left front pocket so that I can scribble and jot down ideas as they pop into my mind. In 2014, however, Preben and I had an idea that almost came to life, and I want to share with you what I learned from that.
What was skydrone?
We wanted to make a stock photo and video site that focused on imagery captured from drones. Our clients would be newspapers, PR, entertainment ++, and we imagined private users and companies would use our pictures and videos for presentations, cards, websites etc. So if a tv-channel or production company wanted scenery for an intro or a filler in a show, they would come to our site, browse through the videos (with previews) and order them to incorporate into their show. We thought this was a very good idea, and after a few chats we decided to start planning it a bit more seriously.
Chiseling out a plan
Our plan was quite simple. Preben worked as a journalist for a local newspaper in my birth-town Bodø, and somehow he had come across someone that needed some shots of scenery from where he lives. We had both bought a drone (or 3), and we would pretty much jump at everything drone-related. A few days later an idea started to emerge: what if we could make a stock photo site that specializes in drone photography? We also threw video into the mix (and that obviously made a lot of sense). Ok, fine and dandy, but where do we get the photos and videos to put on the site? We figured that it would be smart to let other people upload their photos and videos to our site for us to sell to producers etc. But why would they upload the videos and photos on our site? Hmm, percentages of sale as revenue! We figured that drone stock photo and video would be a niche market, so with as little as 3% of sales value, we would still make some good money if we could sell to enought buyers. Preben had some contacts he could leverage to throw in sales pitches. Preben and I have a less than successful history as doorsellers for a company that sells alarms, but Preben has worked in sales later on as well and is good at selling! He would be our money and sales guy, and I would be the tech person. We looked around a little and reused some of my documents from my bachelor thesis for the mission statement, requirements and specs, and we found a Confidentiality Agreement that the team would have to sign to protect our awesome idea from copycats. Then we sent an email to the professor responsible for that years bachelor thesis at my old community college and pitched the idea.
The team
We both had full-time jobs and little spare time after work, so to put down enough hours we outsourced the implementation of our ideas to a team of senior year students at the University College I graduated from only a year before. They had the pleasure of trying to implement the core functionality of our project as their bachelor thesis. As I recall, they all had programming experience from before they started their bachelors degree in IT and Information systems, so we were quite confident that they would be able to implement more or less all the core functionality, and that Preben and I would only have to do minor adjustments and further development afterwards. We knew that they wouldn’t be graded based on the code or product of their thesis, but instead on a rapport they had to write during the development process. Nevertheless, if they could create a site with upload/download functionality, preview and payment options, we would have a MVP we could pitch to investors and develop further.
Challenges
Oh, how unprepared we were… We started by creating a shared folder on my Google Drive. This was our common area to share documents, like mission statement, functional specifications, contracts etc. The code was shared in a dropbox-folder for reviewing along the way. All fine and dandy, but managing a team that was on a remote location was harder than we thought. It didn’t make it easier that Preben and I also were on completely differen physical locations!
To help us communicate and keep a record of the decisions we made, we created a facebook-group for our project where the team could ask us questions, we could ask for status-reports and share screenshots and other files.
Whenever we needed a meeting, we would use skype.
Our first couple of months ran past fast. The dev team were given free reins to select a framework and time to get acquainted with their selected framework. We received updates from them at irregular intervals, and there was never any big issues as far as either of us could see. Preben and I had almost daily talks over the phone where we discussed the last status from the dev team, and we planned other stuff related to our product. Things we thought was important at the time, but hindsight 20/20 we should have put more effort into communication with the team.
We made a specification and a mission statement for the dev team that stated (loosely) what our goal was. A site where anyone could sell their dronefootage while we took a small share of their profits. We agreed that paypal was a good way to go as a payment service since it is well known, has lots of users and should be well documented. The team chose a PHP framework called Symfony that they thought would suit the task given that we wanted a prototype/MVP that we could scale up later. The choice was good given the parameters we had given them, but we probably should have given them a lot more slack so they could make the prototype and complete it instead of spending time to get to know a new framework.
We also wanted preview functionality, another nice to have thing that we should never have mentioned before upload, download and payment was completed. Needless to say, there was a great deal of time spent on unimportant functionality. This caused a whole lot of frustrations from me and Preben, and surely from the dev team as well, although they seldom told us directly. To be frank, we never asked either, so it was our fault. We did however ask what challenges they had, and what we could do to make the development process more smooth.
What I learned
There’s a lot of planning required before starting a project, especially if you want others to partake in the development. If Preben and I had discussed the scope better and had a clearer view on what was supposed to be part of the prototype and what was not in scope, we could have managed our expectations and most importantly, we could have communicated our expectations better to the dev team.
We also should have talked more with the team regarding their level of expertise and experience, since a lot of time was “lost” due to learning.
I’m not a big fan of estimates, but having a ballpark estimate of the size of each functionality in the project probably would have helped us manage the time and effort better. Don’t get me wrong, estimates are fine and dandy, they are just never correct as there’s always something unforeseen that will have an impact on them.
Instead of using Google Drive for managing the code, we should have set up a repository on Github or Bitbucket. They would probably have had to learn using git, but it’s pretty easy to learn and would have provided them with a very useful skill for later jobs.
We should have implemented weekly reviews earlier in the process to keep an eye on the direction and velocity of the project, and to be able to nudge them along when they got stuck.
Our communication-skill were not excellent. The more frustrated we got, the more we let it shine through. This made us use the “whip” more than positive reinforcement. Not a good way to lead when the team was already pretty worn out.
