Get Better Tech Outcomes: Part I - GHQ's Lego Bricks Approach

Do you find getting the business outcomes you wished for in software projects difficult?

Ever wondered why, and how to overcome it?

Here's our take, having done over 50 projects, and being both sides of the table. We once were clients and also the engineering team.

Off The Shelf + Outsourcing: Cheap But Not Solving 'The' Problem

We tried off-the-shelf technologies ourselves; They may not work the way we need them to, or require higher "tier" packages (read: prices). Even then, these do not fit like a glove 100% of the time.

The time taken to experiment, integrate with client operations, and figure out if it is a scaleable solution has already wasted precious opportunities. Why doesn't software "just work"?

For outsourcing, the contract you've signed may have been too specific - at the expense of everything else! Support becomes distant, business outcomes start to lag, and the changes you wish to see become priced out of your budget as its all a new change request.

DIY: Expensive, Takes Too Long

On the flip side, anything DIY takes more time to build for the same outcomes. This may involve hiring your engineers, but this requires technological experience and a team who have produced similar outcomes before.

How does a business overcome this cold-start problem?

A Balanced Approach

Growth HQ's approach is to have a fine balance for "Buy vs Build" decisions. If it takes more than 3 weeks for us to build something, we're better off buying a simple version first, until it's timely to connect different pieces and form our solution.

In that time frame, we will stress test and validate if it meets our needs at scale, and how else to close the business gaps. We have a better sense of whether to put in more investment or wait for a better time when there may be available solutions to "plug and play" to get the job done.

In both scenarios, we still require the ability to 1) Connect the systems and 2) Service any changes. These are common in any system setup, and something that cannot be completely automated.

Scale

Scaling means that behind your phase 1 or MVP - how else might the business utilize this?

How do we reach healthy unit economics? Is your cost of acquisition higher than what it should be? How do you know? Can the tech sustain itself without maintenance?

How do we make it robust enough so that the tech works for us, and not the other way round?

Being able to articulate and answer these questions upfront indicates that there is a high chance of success, as the key factors of risks at scale are being considered.

Scaling needs a separate writeup, but this is a broad overview to consider in terms of just software products.

You would need a little bit of technological understanding to do this, as with any company with a Chief of Product, Information, or Technology.

Results

Over 10 months, we've consolidated software playbooks and "plug and play" modules that are ready for business use. It may require some tweaking, but the base code is there.

This means your time to market is faster - what you want is sales, and finding market fit.

Interested in knowing more? Contact us here today.