9 - Deciding What To Build

My last post explained my process for finding a slice of expert knowledge in which I could build a beachhead of a business. It detailed how I landed on transfer pricing, the pricing of intercompany transactions for tax purposes.

Here’s how I went about turning the identification of that slice into an actionable strategy.

Minimum Viable Context

First, some context about transfer pricing.

The core principle of transfer pricing is that transactions between connected businesses need to be made at arm’s length - i.e. the prices that would be paid in the absence of any connection. These rules exist to prevent organisations from shifting profits from high tax jurisdictions to low (or no) tax ones. In their absence, a group’s Cayman Island entity could charge the group’s UK entity £20m for an hour of basic administrative work, thereby shifting the entirety of the UK entity’s trading profits out of UK Corporation Tax and into the Cayman Islands’ (very competitive!) 0% rate.

There are two elements of transfer pricing:

1. Policy design - the identification and documentation of the correct transfer pricing policy given the relationship between the group entities - i.e. how transactions between them should be priced

2. Policy operation - making sure that the transactions between the group entities reflect that identified policy

Getting the Frame

I did three things to frame the initial strategy for transfer pricing:

Firstly, I wrote a positioning statement. For anyone interested in learning more about positioning statements, I recommend this excellent First Round Review article. The output was:

Secondly, I wrote a very high-level vision of the products we’d build across policy design and policy operation. For each, I wrote out my ultimate long-term vision coupled with what they’d look like near term.

Finally, I used the Business Model Canvas to capture my initial thinking about the constituent areas of the (soon to be) business across the following categories:

• Customer Segments

• Customer Relationships

• Value Propositions

• Revenue Streams

• Channels

• Key Activities

• Key Partners

• Key Resources

• Cost Structure

These three documents were all written in pencil (figuratively speaking that is; literally they were written as Google Docs). I’ve already made many changes to the initial versions. I find it invaluable to write things out. It helps clarify my own thinking and expose blind spots. It helps me communicate more clearly to others, whether by sharing documents with them or informing other communication. And it provides accountability through a source of truth as to what my thinking is that I can then go back and actively test and revise in light of new information.

Breaking Ground

It was then a case of deciding what to build first. My original thinking was to start with policy design with a form of marketplace to connect startups/scaleups to providers of transfer pricing advice. Here was a great example of the value of the above documents. I shared them with a friend who is helping me build our first product prototype. He saw things differently and helped me see that I’d been thinking too linearly. And mistakenly concluded that because policy design predates policy operation for an individual business, it needed to for our product strategy too.

I came to see that the best place to start was in policy operation; building a product for startups/scaleups that already have transfer pricing policies in place to automate the process of calculating and processing the ensuing intercompany recharges. Our Recharger product will do for that process what cloud accounting systems have done for filing VAT/GST/sales tax returns. And reduce what has been a multi-hour manual process to a 5-10 minute review exercise. This strategy had the added benefit of enabling me to leverage my existing network within accounting tech.

Moving Forward

By late July, we were ready to move forward with Recharger as the first product. At the equivalent stage with Chaser, my first startup, we could just get started with building the first prototype. I’d run credit control as a process across multiple finance teams. I had a good enough idea of what the product needed to do. With Recharger, I didn’t have the same first-hand experience. I needed to learn from others.

I made a mistake here that cost us about a month of progress. I reached out to a number of the 39 customers I had spoken to in selecting transfer pricing as a slice. I was looking for people who were willing to demo me their current process for calculating and processing intercompany recharges. Some were in-house finance people. Others were accountants who did these recharges for their clients. In the end, I was only able to get one demo. This was partly due to people being away during the summer, combined with the infrequent timing of when they run their recharges at present. But it was also an understandable reticence to demo, when doing so would involve showing transactional data. This was especially prevalent for accountants where it would have been their clients’ data. And whilst I offered to sign whatever non-disclosure document they wanted, that just added friction for them to do me a favour.

In the end, I took to asking people to just describe their current processes. I drew the line of the 31 August to get as much information as I could to give the best idea of what Recharger should do. We then built a very light demo’able prototype that we could put in front of these same people for feedback. So that they could comment on specifics without needing to show their (or a client’s) data. This wasn’t a fully functioning software product but rather a series of wireframes (mocked up screenshots) using Figma. We’re now pretty much there with this demo’able prototype and already have 13 calls or meetings booked in for the w/c 4 October when we’re running a round of feedback with target users. With hindsight, we’d have built this show and tell prototype earlier rather than wait for information we were unlikely to get. We’re excited to get this feedback and then work on having a sellable product by the end of the year.

In the first post of this series, I explained my plan to get to a regular cadence of writing about the present day progress, plans and perspective in building my next startup. And that initially there was a retrospective backlog to clear to get to that present day. We’re almost at that point. Next week’s post will set out a key step I undertook to connect the above plan for transfer pricing to the mission of the emancipation of expert knowledge. We’ll then be fully up to date. Thanks for reading and stay tuned!