Do you know what isn’t fun or rewarding? Spending time and energy building something nobody wants.
I’m embarrassed to say that this has happened to me a lot.
It turns out there is a lot of material out there that addresses this problem. The general idea comes down to finding out if there is a need before you invest in building a product or service.
In some cases you can find out whether there is a need without writing any code at all. I found this to be very counter-intuitive as a programmer. Especially since programming is the exciting and fun part.
Don’t get me wrong. The implementation is important. So is the architecture. And most of those other fun bits. But none of that will matter if nobody pays for what you create.
There are a few places I wish I had put this idea into practice over the years. Looking back there should have been warning signs. Even now I’m not sure if I didn’t see them or simply chose to ignore them.
Where did things start to go wrong for me?
I started building an application based on QR code technology. The idea? Combine printing technology with web technology and sell it to Real Estate agents.
My partner and I thought it was brilliant. And maybe it could have worked? But there was at least one big problem.
Neither of us were Realtors. Neither of us knew many Realtors. We didn’t talk to any Realtors before we started building the product. We had to go out and seek Realtors when we had something finished to show off.
We created a product for a market we knew nothing about.
I’m not sure if we managed to get more than one person to pay us for our product. Two years later we sold the company for a meager sum.
As someone who is a fan of Domain-Driven Design I should have seen this coming. We built the whole application without a domain expert guiding us.
We thought we knew what they wanted. So we built it.
Thinking back now, I was focusing only on the technology. It was neat. It was cool. Of course other people will love it!
As a programmer, I find this trap is far too easy to fall into.
Takeaway? If you are not the domain expert, and nobody else on the team is a domain expert, this should be a red flag. Either find someone to be the domain expert or consider whether you should work on the project at all.
One of my partners and I connected with an industrial research & design company. Our role was to help them repurpose their concepts and productize them for consumers.
It was quite exciting. They were working on extremely cool ideas. We couldn’t wait to pitch our ideas for getting consumers to use their technology.
Most of their work lended itself to wearable technology. This was still new at the time but was getting quite hot.
We underestimated how difficult it would be to define a market for these new concepts.
To get started, we picked one prototype and started to shop around the ideas we had for it.
There was no lack of people with great ideas for what we should do with the technology. Like us, most people could see the potential. There were so many cool things you could do with it!
Golfers could see how much potential was there for golf.
Medical professionals could see huge potential for medicine.
Runners could not wait to have it help their form.
Gamers saw a great solution to input related problems with Virtual Reality.
The list goes on. We suffered no lack of ideas for how we could use the technology.
That is when the chasing began. Whoever had the most recent interesting idea would steal the cycles for a spell. Until someone else had another clever idea. Or until we hit a dead-end and had to start from scratch again.
That use case someone had for a specific niche? Turned out it wouldn’t make market sense. Or the price point wasn’t right. Who’d build the related app? They aren’t returning our emails anymore. Oh, they partnered with someone else doing something similar. Now what?
Rinse and repeat.
We chased our tails on this for several years. The true believers in the core technology never gave up hope. There was always a new potential angle. Another take on the core technology.
My takeaway? Finding a market for a product that already exists and never had a market to begin with is tough.
I agreed to be the technical co-founder for a fintech startup. The project sounded like a great opportunity to flex my software architecture muscles. We were going to lay the foundation for some amazing software.
It was a three phase plan. We worked on Phase I for the first six months. It was a big job and we had limited resources. Things were rough but exciting.
Six months into bootstrapping the project, we decided to pivot. Rather than working toward completing all full three phases, we were going to focus on Phase I and build that into a business.
Phase I, for all intents and purposes, was a general-purpose commodity product. A product for which the market was already saturated.
We picked a niche market to focus on but our new marketing plan didn’t kick in for another three months. It did not go well.
Another three months passed.
With no sales, we decided that we couldn’t keep paying my salary. And that was that, for my part.
One year. From start to finish.
My biggest takeaway? Commodity products are hard to sell unless you know your market extremely well.
What all these lessons have in common is putting the cart before the horse. Building something or taking something already built and trying to find a market for it is hard to do. In the future I need to take time to understand the market and gauge user interest before investing too heavily in code.
I care about the protection of your data. No spam!