How to start a software team
Don't start with developers
There's a story behind "Undeveloper" as a company name. Some time around 2010 I was doing the circuits on London's startup scene, attending meet-ups and generally networking. At the time, I was looking to sink my teeth into a startup project as a founder and thought that a reasonable approach would be to hang out with other like-minded people and see what connections I could make. I found myself going to a lot of co-founder "speed dating" events, and the like.
It wasn't a wholly bad idea — I ended up meeting some great people and am still connected with a few — but what I found, much to my surprise, was that the conversations almost always took a particular form:
- An "Entrepreneur" has an Idea (henceforth to be known as THE Idea)
- The Idea is Killer (natch), and also usually top secret (or, more theatrically: Under the Radar)
- The only missing piece of the puzzle is a Developer, who will do something special (presumably "Development", whatever the hell that is) to magically transmute The Idea from purest hot air into The Next Facebook (or similar. Sometimes "The Uber of..." or "Tinder for...". You get the picture.)
It's worth mentioning at this point that even the comparatively naïve me of 2010 knew that most of these folks were a few steps short of a business plan, to coin a phrase. Speaking of which, my first questions (and, as it happens, these are the same questions I ask founders today) were:
- What about product management?
- What's the business model?
I ask them in that order because, frankly, I'm a soft touch and like to hear people out, and not having a business model is basically a conversation killer if you're trying to pitch your idea to me (although that said, there are several answers to the first question which — to me at least — have a similarly chilling effect!)
Seriously though (and if you don't believe me, the popular startup literature is replete with this , etc.), an idea by itself is almost entirely worthless!
If you've thought of it, chances are so have literally hundreds, perhaps thousands of other people. Some of those people will be much better positioned than you at executing on it too.
At this point, I'm going to make what is perhaps an excessively sweeping statement:
Of course, nobody at these networking events wanted to hear anything remotely like that. Most people were absolutely convinced that their idea was just a software developer away from success. Upon discovering that they were actually talking to somebody who was capable of writing software, the entire tone of the conversation would shift immediately. Suddenly, I was not a peer, but a prize to be fought for and won. I went from feeling like one of a brave band of intrepid sailors, bobbing around on an ocean of possibility, to the horrible realisation that these were fishermen — and I was the fish! This effect was so prevalent that I actually went to one co-founder networking event where people were given coloured name badges to wear — blue for "entrepreneur" and red for "tech". I mean, come on, seriously!?
Asking about business model and steps to get there is one thing, and usually people can waffle on relatively cogently about plans with a bit of practice at thinking on their feet. One other thing that they seemed to struggle with was any questioning of the idea itself.
"Have you thought about..." or "I think you might have a problem with..." or "Do you think the market for that is..."
Questions such as these should be highly relevant for anyone looking to get involved in a business which hasn't yet launched (arguably any business). In fact, entrepreneurs who have done any amount of pitching for fundraising will be well acquainted with being brutally cross-examined; and those who have successfully raised will presumably have developed a strategy for answering tough questions with slightly more tact than "well, it's my idea — take it or leave it!"
This is how Undeveloper was born. Rather than throwing my lot in with them, I decided to try and work to educate would-be founders on a sensible way to get started building an initial software product to test the market (i.e. an MVP — or Minimum Viable Product to the uninitiated )
I would try to convince those that wanted to find a developer that they were missing some steps, and actually what they wanted was not a developer — an *un-*developer. Or in other words: me.
This turned out to be a really useful approach, because it drew a very clear line in the sand with startup clients: if you don't want to engage with the basic principles and you want to skip straight to hiring a developer, good luck to you, but count me out. The corollary is that the clients left in the conversation after that very early vetting process are generally good clients to work with.
Okay, so if we don't start with a software developer, where do we start?
Do start with a business model
Sounds painfully obvious, right? As I'm writing this I'm actually sitting here worrying that it's too obvious.
I think the real issue here is understanding how watertight a model you need at this point. The short answer is: not very. Let's think about it:
- You have an idea which is almost certainly untested
- You may or may not have done some market research, but if you have it's probably been limited by time, budget and access to information
- You haven't built anything yet
- You haven't gone to market yet
That leaves a lot of question marks. So, realistically, your business model has to be both provisional and agile! Incidentally, the word agile — much overused and misunderstood in tech circles — should be taken here to mean simply "designed with change in mind".
If you're trying to get a co-founder on board, or just engage with discerning partners like us, more important than whether your model is watertight is simply that it exists at all. Essentially this is a credibility issue. Working up a back of the envelope business model isn't exactly hard work. If you haven't taken the time to do it, and you are already fishing around for co-founders or collaborators, how credible do you think you look to them? How organised? How committed; how serious? It's a little like turning up to a date shabbily dressed and without combing your hair. Lots of dates don't work out, for good reasons, the most common being because there simply isn't enough mutual interest or attraction. That's a good reason to say, politely, "thanks but no thanks". A not so good reason is because one party simply hasn't made the minimum effort required to make a good impression. Pitching your idea without a business model is the entrepreneurial equivalent of not making the minimum effort.
At this point you might be thinking: "that's all well and good for attracting co-founders, but if we're talking cash here, why should a contracted company (like Undeveloper) care whether I've got a business model or not?" Well, two reasons: firstly, demand massively outstrips supply in this area, and we have to turn down a lot more business than we can accept. Secondly, our experience tells us that clients without a plan are orders of magnitude more likely to string us along, wanting to have an endless series of (usually free) conversations, never wanting to pay for chargeable advice on time, or at all and — much more often than not — wind up not launching at all. Turns out starting a business maybe isn't as fun as we thought...
In short, a startup without an initial business model is an enormous red flag to a potential supplier and probably should be to co-founders too. (Certainly if you made it past the first part of this article and are still dead set on hiring that software developer and are planning on offering equity as part of that package, I'd humbly suggest that if you find someone crazy enough to work for less than market rates, or nothing, in the hope of realising a return on an idea without a business model, then maybe you deserve each other...)
Do think about product management
Okay, so you've got a business model. Now can we hire a developer?
Sure, but what are they going to build? Do you have:
- UI designs?
- A detailed specification of behaviour (often referred to as "requirements")?
- A go to market plan for the MVP?
- A list of things to build in an order determined by aforementioned plan?
- A sensible strategy for dealing with the information coming back from users and the market which needs feedback back into adapting the business model?
To be honest, I stopped this list at six items but I could go on forever. So much of bringing a software product to market is product management and, vitally, so much of what makes software products successful is as a result of impeccable product management. Think — really think hard — about the software products you use regularly, and pay for, and love. Do they feel like they've been chucked together in a few weeks on the back of an idea, or do they feel beautifully crafted, designed with usability in mind, aesthetically pleasing and fitting beautifully the problem space they are designed to solve?
Okay, you probably won't have the resources to build a world-class, award-winningly designed product with all the bells and whistles when you're just starting out. But that doesn't mean product management doesn't matter right now. In fact, it matters more than ever. Unless you're independently wealthy or have found some seriously generous investors to write you blank cheques, your resources are so limited right now that you simply can't afford to squander them with a half-baked MVP.
An MVP is like a controlled experiment, the goal of which is to return you information. One of the best results of an MVP is confirming that you do indeed have a solid product/market fit; and ideally pointing the way towards where future investment in features might be most richly rewarded. As with any experiment, there is a very real danger with an MVP that your test conditions won't be conducive to collecting the data you need. Launching a shitty product is a surefire way to scupper your chances of collecting genuinely useful feedback. Prospective users are liable to be so distracted by poor usability (or even just poor product positioning) that they aren't able to answer the all important questions around product/market fit.
This is not just about the quality of the product itself; it's also about the quality of the processes around the product. For example, it's no use spending your runway building a beautiful product and collecting feedback from users if you don't have the product management processes in place to assimilate that feedback, analyse it and adapt your development plan accordingly.
Hopefully this is all making sense so far. If it sounds like a bit too much like abstract consultancy-speak then I'm sorry to tell you we haven't even scratched the surface. This stuff cuts to the very core of what launching a startup is. I'm going to state it as plainly as I possibly can:
Okay, point made, I reckon. But how do we get product management. Am I suggesting hiring a Product Manager instead of a software developer? Surely not! We haven't even launched yet and we're already hiring "managers"!? That's not very startup!
Well, firstly I'd say don't be put off by the word "manager" — an unhelpfully generic term in business which can mean anything from managing a whole company to managing a cash register!
The short answer is no — I probably wouldn't recommend hiring a dedicated full-time product manager at this stage. If budget allows it comfortably and you have someone great in mind then certainly it's an option, but the really important thing about product management at this point is that (much like the business model) it should exist!
Can founders do product management themselves? Yes, they can and very often do. However, it is a mistake of the highest order to imagine that product management isn't a rigorous discipline in its own right. You don't get product management "for free" because you're a founder with an idea or vision. If you are a founder and you want to do your own product management, the very best recipe for success would be that you'd experienced serious commercial product management before. Failing that, I would strenuously advise educating yourself as deeply as possible in the theory and practice of product management. Read books, blogs like this one, attend webinars, find experienced people in your network to help advise, etc. etc.
The other very serious danger of founder product managers is the crippling myopia that so often affects founders. Ever heard the phrase "a face only a mother would love"? It's a terribly unkind thing to say about someone, but the reason it makes us laugh is because we all know that parents think their children are beautiful and wonderful, even when objective evidence appears to suggest otherwise. Any founder can find themselves so attached to "their baby", that their sense of judgement is compromised to the point of rendering their ability to product-manage useless. This no more so than if they originated the idea in the first place.
What about software developers? Surely if they're half decent they'll be "product minded" enough to cover it off in the short term? No!
Besides which, do you really suppose that your software developer has time in their day to do two jobs?
Some recommended further reading on product management / product managers in early stage startups can be found in .
If the above discussion seems very doom and gloom, it really isn't meant to be. The good news is that all of this stuff is eminently doable. In fact, thousands of startups manage to wobble their way off the ground every year and make it past the MVP stage.
It's not necessary to hire an army of specialists early on, neither is it necessary to spend months and months working up perfectly crafted business models and product plans before thinking about building.
When we at Undeveloper workshop with clients on initial product ideas it feels terribly disorganised — as good creative work really should. The real value in nearly all creative enterprises comes out of the creative process itself, so the tools for generating that value are generally very crude indeed: voices, minds, open ears, pencils and paper (the aforementioned back of envelope will do!) are usually enough. For those worried that planning and "management" will suck all the creativity out of the room at this early stage, don't be. In our experience, it's just not really possible to suffocate an early stage project with bureaucracy — that particular danger comes somewhat later down the road!
References & further reading
- Nobody is going to steal your startup idea
- 5 Reasons Why a Good Business Idea Is Never Enough to Succeed
- What To Do If Your Startup Idea Already Exists
- Minimum Viable Product: a guide
- The Lean Startup
- Why Business Models Matter
- Product/Market Fit
- Founders and Product Management: A startup story
If you're thinking about launching a startup and want help getting started planning the tech & product side of the business, check out our Virtual CTO service or drop us a line — we'd love to hear from you!