2025-10-14 5 minute read

Building Bad Products

Another week past, and another set of lessons in the world of pre-revenue business. This week has been all about social media; laying the foundations for distribution of whichever hot new products I launch in the coming weeks. I wanted to spend some time talking about how moving to a more product-oriented mindset has changed how I think about building things in the corporate world, and ultimately why the small/solo businesses mindset is so valuable.

Product Oriented Thinking

When deploying technical products, there's only really one question that matters, and that's: can anyone buy it. Sure there's the whole will anyone buy it, but I'm talking more in the very literal sense of can anyone actually go to your website, click a button, enter their card details, and actually pay you for something. It turns out that although there are many online payment providers, and even tools which let you skip this entire setup (like Etsy or Gumroad), doing this for a custom technical product where payment unlocks some feature/functionality is non-trivial but a great lesson in engineering.

Don't get me wrong, I've been using Stripe so far and integrating it (although non-trivial) is still pretty simple, but doing so has changed the way I think about the things that I worked on while enjoying the safe haven of a corporate job. I think that although technical products built inside organisations can be good, the majority are not, and this stems from both a lack of competition, a captive audience, and what I would call 'tool oriented' rather than 'product oriented' thinking.

For example, lets say I take four great engineers, pay them each $200,000 per year, and ask the team to build a tool for the company which does something interesting and useful. For $1,000,000+ after costs I'm expecting something really quite special, I'd expect other people in my company to use it daily, I'd expect the design to be nice, the feeling of using it to be nice, and most importantly, I'd expect the time taken for other people to learn how it works and what it does to be essentially zero. It should be intuitive and obvious what it does and why it does it, after all, with that money I could've bought a cozy studio flat in London and forget about this whole software engineering thing.

However, if you've been in the corporate-tech world you'll know that this is rarely the case, and here's a solution; Add an internal payment mechanism to your product. If another team wants to use it, then make them 'pay' for it, and use that payment as a source of truth for how well your $1,000,000 dream team is doing. If your gut feeling is that this will never work, then your company might be at the early stages of a tech-debt death spiral, but if this sounds like something you could reasonably implement then there is hope in the universe.

Money Is The Metric

This revenue centric evaluation aims to mimic what would happen if your dream team were left exposed in the big and scary open market. If they built buggy trash, their users will want refunds. If the onboarding is impossible or takes months and many many meetings, then nobody is going to want to use their product. So what's the downside to this approach?

Turns out that if you're not in a global mega-corp (say 10k employees+) then you may only be 'selling' to literally one or two people, which means that you'll essentially enjoy a full monopoly over solutions to their requirements. This is a bit depressing, since if you're in such a company you'll probably have a tech team who will probably be okay-but-not-amazing and things will just be 'fine'.

Now I don't know about you but I'd rather not settle at 'fine'. I'd rather reach for something 'great' and risk it being 'good', so what can you do? The only path it seems is to look on the open market, see which products already exist, and even better, which ones are in the launch/growth stages and are operating at a loss (so you get a sweet deal). And even-even better, tell your tech dream team to stop working on 'fine' products entirely, and work only on integrations. Make your internal systems play nicely with tools that you'd like to use and you can benefit from the best of all worlds.

This is purely theoretical

In practice, I know that there are many roadblocks to avoid this approach to engineering, but I hope this is still a useful thought experiment. Also, as someone now in the scary open market it's of course in my interest for you to start looking outside 👀. Anyway, I hope everything is going well wherever you are - I happen to have spent yesterday off on the beach and now resemble a lobster, so wish me luck in my journey to recovery and hope the weather is beath-worthy wherever you are!

Next week I'll cover exactly what I've been doing in the social media world after passing 40k views so far on Threads 🚀

Thanks and all the best,

Oliver

Previous Episode: No Plan Survives Contact