Internal Tools

We built a lot of software at Wherehouse.

We also built things that we probably didn’t need.

That became one of the more useful things I learned about building products.

The starting point was usually an operational problem. Something was slow, someone was doing the same thing twice, information was getting lost somewhere, or a process simply didn’t scale.

The temptation was to build software immediately.

Sometimes that was the right answer.

Sometimes it wasn’t.

When we started Direct-to-Retail, salespeople were using a third-party sales app to take orders and manage their work. We could either integrate it with the systems we already had or build our own.

Most of the backend was already there from D2C. WMS, OMS, delivery and logistics were already running.

We looked at what we actually needed from the sales app.

Taking orders.

Salesperson performance.

Retail store information.

Most of the other features weren’t useful to us.

So we built our own sales interface instead of integrating a much larger product for a small part of what we needed.

The billing software was the opposite.

We tried to build our own system because billing was taking too long. On paper, it looked like a good problem for software.

It wasn’t.

The difficult part wasn’t creating invoices. Payments came in instalments, through cash and bank transfers, with adjustments along the way. The accounts team still had to reconcile everything with Tally.

We ended up giving them another system to maintain.

That was a bad product decision.

There were other things we built that didn’t end up being useful. I don’t remember most of them now.

That’s probably fine.

The things worth remembering are the ones that actually changed how the business worked.