You’ve got your app idea, you’ve created a series of wireframes, your branding is on point, now you’re ready to go!
Building your software development team is just like building a backyard swimming pool. You don’t just go out there with a shovel and start digging. You follow a process:
Know what you want, when you want it and how much you’re willing to pay
A few months ago, I was working with a startup in the home loan space. They saw an opportunity in the market to moving their loan application process online and wanted to know what would it take to bring this idea to a reality.
The first question to always ask – what is it?
There’s a number of ways to describe what you want. Wireframes, Use Cases, User Stories – they all meet a need and there’s never really a right or wrong way. But its essential as a first step – how would this “thing” work? How many steps are there?
Then there’s the time frame and budget. Give yourself some wiggle room. You’d rather over estimate than underestimate. Expect to be +/- 50% accurate.
Be clear – what is essential for version 1?
You know what you want, but what is essential? Of course you want the bells and whistles. And of course all these little bits and pieces are important. But you know what’s more important? Having an actual, working product.
Case study – Android vs iPhone – two very different ways to release a product
In 2007, at the Macworld keynote, Steve Jobs presented for the first time – the iPhone. I remember back then, there were hints & rumours that Apple was looking at a mobile phone, but nothing substantial.
Then, out from nowhere:
BOOM! The iPhone was launched to the world.
Compare this to version 1 of Android:
Back then, Android was for people who either couldn’t afford or didn’t want to spend +$1,000 on their mobile phone. Android had the reputation as the “poor man’s” iPhone.
But Android got better.
Android 3.0 (Honeycomb) was released in 2011. Android 4.0 (Ice Cream Sandwich) was also released in 2011.
It’s difficult to pin point when Android caught up. You could say it was Jelly Bean (2012) or Kit Kat (2013) or maybe a bit later. Certainly by 2015 with the release of Lollipop Android had certainly caught up.
The point is, you can go dark and quiet. Or you can release increments. Quiet and Dark has a massive risk. Remember Microsoft’s mobile phone? What about when Microsoft bought out Nokia in 2013?
Or even worse – what about Blackberry? Interesting a Google image search brought up this result:
There was a time when EVERYONE had a Blackberry. And now they don’t. The main reason why, was that they took too long to adapt.
Don’t take too long. Cut out everything you can. Then go back and cut more out. You can always add it in version 2.
A good test I often run with clients is to set each item a priority. If you have >50% as a priority 1, then perhaps go back and see what you really really need
Offshore or onshore? It doesn’t really matter
There’s lots of reasons why you may or may not want offshore or local developers. Your budget will be the primary driver.
As a rule of thumb, just know that while an offshore resource can reduce your development costs by 80% or more, you’ll pay for that in your time. Primarily Project Management.
Be clear – what you done now and in 6 months time
This might sound odd, but the curse of startups, founders & entreprenures who have raised too much cash, is that it tends to burn a hole in their pockets.
Warren Buffet famously said:
Of course you want to go to market as quick as possible, of course you want to get your thing out there. Just be aware – a developer can get through a LOT of work in a week, month or quarter. It might look like a lot of “work” to you – but hopefully they’re good, they know what to do and they want to put their head down and get on with things.
Some questions to ponder:
- Graphic design – once the design is “done”, then what else is required?
- Mobile – if you’re going to release a mobile version, are you developing cross platform? And then what will you need?
- Support – what sort of support will your “thing” require? Do you really need a dedicated person? Or can someone existing take on those responsbilities
Speaking of responsibilities…
What do you want them to do? Job description & responsibilities
This doesn’t have a to be long, exhaustive list that covers everything. Half a page full of bullet items is sufficient. At least have something written down.
Define the schedule
What are you delivering this week? What about next week? This month? Next month? In order to stay on budget, you need to know this.
Again, this doesn’t have to be exhaustive. A spreadsheet with a list of items is sufficient. Make sure its visible to all and the team agrees. You’ll be good to go.
Hire like a team, not a family
NPR’s Planet Money have a great podcast episode 647: Hardwork is Irreleveant. The concept is simple. At Netflix, they don’t care how hard you work. They don’t care how many hours you worked or what it took to get it done. They only care about one thing: Your ouput!
As part of the employee culture, Netflix make it clear – this isn’t a “job for life”. If you aren’t needed, if you can’t or unable to contribute, you will be let go.
In the podcast episode, they talk about how Netflix was facing a crunch. This was in the early days, just when they had started transitioning from a video & dvd mail-order business to a streaming service. The business had 9 months to get their streaming service up and running. And the engineering team couldn’t deliver it in that time. And so the engineers found other jobs. They knew they would be fired, so they just left.
Another example was a product tester. Unfortunately, product tester roles can often be automated, and this was the case. Its an interesting case study on how to turn the conversation around. Yes, your job has been automated, yes your results to date have been amazing and yes, you’ll do really really well at another company. Just not this one.
Adopt the same attitude – in a professional sports team, if you aren’t up to scratch, then you aren’t up to scratch.
Rinse and repeat!
Phew! You made it this far! But we’re not done yet. You’re adventure has just begun. Next step is to do this again. And again, and again, and again. Rinse and repeat. Where can you improve? What can you do better?
I genuinely believe that development teams are like a living and breathing thing. They have wants & needs, they have emotions, they have good days and bad. And that is all ok.