Things I Wish I Told My Former Founder Self
I’ve been a software developer/consultant for large media companies, big financial institutions and several startups in my career.
I’ve built tools that need to scale within big teams and smaller side projects for fun.
Unfortunately a lot of the time, the code my team and I wrote wasn’t used by nearly as many people as the business first thought (or in some cases closed before it was used at all!).
Unfortunately this is very common in the software development world.
Too often developers go off to build stuff that is challenging or fun to build, but actually it isn’t solving a real customer problem.
All too regularly the teams never validate the ideas with the customers. i.e. talk to them.
When I say talk, I don’t mean just talk, I mean listen.
And by listen, I don’t mean just listen, I mean understand.
This is a very nuanced skill that doesn’t come naturally to software developers, and is executed poorly by many product managers.
An Example
When someone comes into a hardware shop to buy a drill, they don’t actually want a drill, they want a hole in their wall. So even if they say they want a drill, their underlying Job to be Done is to get a hole in the wall. (Actually it might be to hang a picture/hang a shelf/secure a wardrobe…).
A naive researcher would say we need more drills, or perhaps more attachments, maybe a drill specific for hanging photos…etc… They might be right in the short term, but if you can give customers a solution to hang a picture with sticky back tape that leaves no mark and is cheaper and easier then actually that might be a better solution that will win out in the long run.
To get to this solution requires a real understanding of the customer, their behaviours and their problems to create a product that will actually work.
Software Developers
Software developers are in high demand these days, because they can build systems that can work for millions of customers, rather than ‘normal’ manual people that can only deal with tens or perhaps hundreds of customers.
This has a strange demand on your time as a developer to show new features as quickly (and therefore as cheaply) as possible.
But what I have seen time and time again is a rush to build new features that don’t actually help the customer.
There is a fine balance in a startup between iterating new ideas quickly and solving critical user needs effectively. This is very difficult and there is no perfect answer.
Let me add that it is hard to write bug-free and scale-able code, especially in large systems where there are huge dependencies. If developers had their way, they would probably rewrite everything from scratch every few months to make their code ‘better’!
User Interface
A huge challenge for software development is getting the User Interface / User Experience right.
Again to solve this area best, you really need to sit down with customers and watch them use your app and really understand them.
Almost always there are some very simple things (e.g. removing one step in the signup process) that can double your conversion.
Estimation is Hard
Estimating any task is particularly challenging, even when breaking it down. It very often leads to delayed delivery which causes stress on development teams to deliver less than perfect code which of course has huge effects on the end use.
The Real Problem
The biggest problem that I have seen time and time again, is not getting code written, or iterating new ideas, but that businesses do not focus on really solving the customer’s needs with the code that is written.
It is to be kept in mind that the customers needs will likely evolve over time, and so continual customer conversations are the most important thing you can do.
I think this is true of not just tech, but any business and it has taken me far too long to really appreciate and understand this.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
I wrote a post about 5 Lessons from a Startup which highlighted some other useful learnings and about Estimating
