Invariant 1 - Think, Then Do

The first invariant is to: Think, Then Do. This aligns with the “Strategy” atomic unit discussed in the introduction. In order to understand this and future invariants, it’s best to understand the underlying principle behind the atomic units and why they are organized the way they are.  As a refresher, the atomic units are: 

• Strategy - Set vision and goals, and figure out how the product teams are going to move the business forward.
• Discovery - Iteratively figure out exactly what we want to build, and how it’s going to work in very specific detail.
• Build - Actually implement the thing you designed in the discovery phase with lines of code.  This should be the easy part.
• Quality Assurance - Make sure that what’s been built both satisfies the requirements, but also works well within the existing system without unintended consequences. Show the software to people.
• Delivery - Deploy the new product, communicate to the world it’s here, and get people to use it and give feedback for future development.

The underlying principle is that, at each successive phase, you are dealing with lower levels of abstraction. And that you should do your best to finish work at higher levels of abstraction before working at lower levels of abstraction. Strategy is often very abstract and exists as documents with words on a page. Building means writing actual lines of code. Delivery involves people using working software. If you’ve done a good job at higher levels of abstraction, things at lower levels of abstraction should get easier.

It’s important that we do a good job at higher levels of abstraction because fixing problems is typically cheaper at those higher levels. Updating a strategy–words on a page–is cheaper and less complicated than refactoring code due to changes in strategy.

Examples:

Zaprite’s strategy includes a line to: “make it easy for people to receive bitcoin payments through business invoicing and e-commerce stores”. That line significantly narrows the range of suitable software solutions to our strategy. If the strategy instead stated: “make it easy for people to earn bitcoin”, maybe we build a Fold competitor instead and people earn bitcoin rewards, or people get paid bitcoin for trading in their World of Warcraft gold. The point is that the strategy needs to be specific but not prescriptive.  

Zaprite’s strategy also includes: “we aim to be wallet agnostic. While we won’t be able to support every wallet that exists, we’d like to support a wide range of onchain, lightning, custodial, and non-custodial wallets.” This is, again, not prescriptive, but narrowing the acceptable solutions to the strategy. It’s not a design or detailed specification, and doesn’t mention a single wallet that must or must not be integrated. 

You could imagine later in Discovery, taking this strategy and starting with the next layer of abstraction: what makes a good wallet for Zaprite to integrate? < List of wallet requirements >. Then down a layer: list of wallets prioritized that we want to integrate and the generic user interface for wallet integrations. Then down a layer: detailed specification on how we’re going to integrate with wallet 1, wallet 2, etc…

By making it clear at the Strategy level that what we actually want to do is integrate with other wallets, we also establish that building our own wallet is not a good idea (before endeavoring to waste time at a lower level). That’s the level of abstraction that we’re working with when setting a strategy.  

While there is an argument that Think, Then Do applies to each atomic unit, we align this invariant with strategy because there is no other way to start than by thinking. As strategy is our first atomic unit, there is no other primitive guiding our strategy than our own ideas. As we descend to lower levels of abstraction, much of the thinking has been done for us already in a previous phase, which makes those subsequent phases more focused.

Thinking Implies Insight and Knowledge:

Anyone can Think, Then Do as it applies to strategy, however there’s probably someone whose job it is to determine strategy where you work. That person could be a founder, executive, or manager. This doesn’t exclude others from contributing to strategy. They’re just not responsible for building the strategic artifacts. People who are really good at setting strategy for product teams leave fingerprints from their respective teams, customers, and competitors all over the strategy. Their teams notice these fingerprints, and it makes them believe in the strategy more. 

In order to Think, Then Do, you have to have insight and knowledge–about your customer, about your industry, about emerging trends, about your business model, about your technology stack. At this highest level of abstraction, that knowledge is going to be broad AND deep. Acquiring that knowledge comes from obsession or duty, but if it’s not there, it’s obvious to anyone who knows a little bit more than whoever authored the strategy. So in order to gain that knowledge, a strategy author must:

Seriously understand their customer: If you don’t have regular conversations with customers, you cannot be responsible for setting strategy. Strategy has an implied prioritization that has already occurred before you’re doing lower level prioritization of features. In the strategy, you’ve prioritized what customers actually care about and how they will respond. It’s terrible if you’re wrong.

Seriously understand their team: The strategy author aggregates the knowledge of their PMs, Engineers, Marketing teams, Sales teams, anyone who shows a spark of insight into their business. He does this by meeting them individually, listening in on their team meetings, and doing brainstorms with them. The strategy author is not an island.

Seriously understand their industry: Domain expertise gets more overrated the further down the layers of abstraction you go, so it’s logical that it matters most when setting strategy. Have international expansion in your strategy? Do you know about German business councils, or Irish securities law, or how long the French eat lunch? You can’t afford to find out later.

Seriously understand their business: Why does the business exist? How does it make money? How should it make money? How expensive is the product to build, and once built, will it generate more than it cost? What metrics tell us if we’re winning or losing? 

Having this knowledge puts the strategy author at an information advantage, and makes them worthy of writing the strategy. This knowledge should lead to you knowing what to do when informing strategy. Some people call this the BIG PICTURE. As annoying as I find that phrase to be in most corporate contexts, if someone has these qualities, they do indeed see the big picture. The next part is communicating the strategy in a memorable and motivating way. Before we get into some examples on how to do that, let’s list the problems we’re trying to solve by doing a great job at defining strategy:

People don’t know what they’re supposed to be doing: 

What would you say you…do here? A good strategy will let people know what they are supposed to do, or at least what the desired team output should be. When programmers or designers don’t know what they’re supposed to be doing, they’ll often build things that completely surprise and frustrate you and the customer. Then the programmer gets blamed for building something worthless, and the CTO has a “tough conversation” with them, when it was the CTO’s fault that worthless software was built in the first place.

People don’t know how their work affects the customer: 

Why does any of this matter? A good strategy will not just motivate, but show the motivation for doing whatever it calls on people to do. A good strategy is post-compromise. There is no more compromise available, which is good because compromise is how you ruin customer experiences. If the customer is well represented in the strategy, then the resulting work done in Discovery and Build will be incapable of fulfilling the strategic requirements by watering down the customer experience. 

Here’s an example of what I mean when a strategy is not “post-compromise”. When I lived in NYC, there were ads talking about how you could use a credit card to take the subway. In 2010 or so, that was a big deal. But technically what you were doing was using your credit card to buy a metro card, then using the metro card to swipe into the subway. The metro card machine looked like a mainframe computer from 1963, functioned about as well, and charged you indiscernible fees after waiting in line for 10 minutes.

Then I went to London for work and just kinda sorta pointed my credit card in the general direction of a box on the turnstile and I was riding the tube. 

NYC had the idea, but compromise ruined the customer experience. How do I know this? Because London exists.

People don’t know how their work makes the business better: 

How do we know if we’re winning or losing? A good strategy will make it clear how to keep score. Keeping score matters and is one of many ways you build accountability into your process. A good product or feature will earn its keep (Invariant 5), but in order to earn promotion or demotion, you’ll need to define how it makes the business better and how to measure that.

Good Strategy

A lot goes into a good strategy, and we’ll cover some specific examples I’ve employed in the past, but I want to start with what I think is the most underrated attribute of a good strategy. It needs to be memorable.

What makes things memorable? It’s reasonably short, well packaged, sometimes funny, catchy, and it resonates. Nearly all the strategies I’ve written over the years attempt to be all of these things, but the one thing I’ve found worth spending time on in order to make strategy memorable is coming up with something catchy. Examples…

Unchained Product Strategy circa 2022: Buy bitcoin directly to cold storage with keys that you control. That was the catchy line. It doesn’t rhyme and it’s not funny, but if you could remember that, the rest of the strategy would fall into view. When writing the strategy artifact, I think I mentioned this line five times. When selling the strategy, I said it hundreds of times. It became a bit of an incantation for anyone working on the project. It was our whole reason for building the 87th way to buy bitcoin.

Zaprite Company Strategy circa today: Make bitcoin payments easy. Any wallet, anyone, anywhere. That’s pretty catchy and memorable. As this is a company and not product strategy, it’s a statement that narrows down acceptable solutions when I start working on different Zaprite product lines. Does this make bitcoin payments easier? Am I expanding wallet choice or limiting it? That’s good strategy. 

A good strategy could have a lifetime of six months or a year, so make it worthwhile to read and do your best to have memorable aspects that will rattle in your team’s heads during that time.

Finally, Examples

There are many perfectly reasonable ways to communicate strategy to a company or team, but I’ll focus on two I’ve employed most frequently.

1. Always write a document called a Strategy Document
2. Sometimes write an imaginary blog post

The Strategy Document should include:

1. A vision overview that is memorable and short.
2. A persuasive business case
3. Necessary requirements
4. Definition and measurements of success

It can have other stuff, but it must have all four of these things.  

The Vision Overview is what you hope everyone will remember by heart, long after reading the strategy for the first time. It is NOT a list of requirements, but may include a super requirement if that is what conveys the essence of why we’re all deciding to go down this path together. Good vision overviews may come off a bit arrogant when left without the context of the corresponding  strategy. That’s a good thing. They also elicit strong responses from their readers: this is going to be hard, this will never work, no one’s ever done this before, we’re finally catching up etc...

Other people will refer to this as other things: A Dream State or Purpose Statement. Whatever you call it, it needs to be short, memorable, and relatable. For Zaprite Payment Links, I might write:

Bitcoiners need a better way to sell products for bitcoin. Most options today are more focused on merchants accepting bitcoin and converting them into dollars than helping merchants earn bitcoin. In a world where merchants and their customers already have bitcoin and wallet preferences, we need a solution that brings ecommerce sales to those wallets. With Payment Links, my store connects to my wallet where I keep my bitcoin. No counterparty risk, no unnecessary processing fees. 

I emphasized the part I’d want to make a catchy slogan in this case. Could it be longer? Sure, but not much. Could it be funny, like at all? Yes. But something like this usually gets the job done. The team that reads this is likely to know who we’re building for, what we want to build, and why it matters. Lots of details to discern, but those come later.

A persuasive business case is going to define who you are building for (define your customer) as well as describe the good things that will happen to the business if you execute on the strategy. At Zaprite, we start with the overall definition of who our customer is: Bitcoiners who want to receive bitcoin as payment online. So when I make a business case for a new product line like “Payment Links”, I say something like: Invoicing (one-off-billing) is a mature product with an established target market. In order to help more bitcoiners earn bitcoin online, we’re creating Payment Links where people can accept bitcoin in their online stores. We’ve identified over 10,000 existing online stores that accept bitcoin, believe that number will at least double if they could accept it our way, and have identified 20 high profile stores that are willing to move to Zaprite payment links when we launch.

If someone suggested building a Zaprite hardware wallet, they may have a hard time detailing how that is going to help people receive bitcoin payments online, which will serve as a warning to the reader.

From there, in order to justify a particular strategy, we need the business conditions understood so the reader can evaluate whether the following strategy is a credible way to meet those conditions. Depending on the type of product line or feature you may ask and answer:

• Why is this good for the customer?
  • You may need to describe personas and break it down. This helps the ____ customer by providing ____. They’ll be so happy because they no longer have to ____ to give us money.
• What is the competitive landscape?
  • Is anyone else doing this?
  • Does this give us an advantage over someone?
  • Why do we have an advantage in building this?
  • Are there barriers to entry that will make this new thing defensible? Do we care if it is or not?
• How is this good for our business?
  • How do we make a profit by doing this thing?
  • Do we reach a different financial milestone (funding? acquisition?) if this goes well?

The necessary requirements to deliver on the strategy may be the hardest part. Our goal is to figure out what is essential while not being prescriptive. The reason is that there is endless creativity, testing, and iterative loops in figuring out exactly what needs to be done, and that is a lower level of abstraction. We’re not there yet, so while we’re still being creative, we are necessarily narrowing the range of acceptable solutions while giving this product or feature some shape. Examples from Zaprite’s Payment Links:

Essential: Zaprite focuses on non-custodial but supports custodial integrations. Leverage the wallet infrastructure/connections from the Invoice product. Capable of integrating with large existing online stores. Supports onchain and lightning payments.

Non-essential: Accounting integration. Receipts after confirmation by email. Unified QR codes for onchain and lightning.

Sure that email receipt would be nice, but would a PDF download be better? What about a receipt repository accessible from the dashboard? It doesn’t matter, because we will figure out receipts in discovery and not in the strategy.

So try to avoid specific features here and certainly don’t do a full on functional spec. Describe what features accomplish when you can, not necessarily what they are.

Oftentimes when you’re listing out the necessary requirements, you’ll find that you need to stage things because of logical or technical reasons. In other words, there will be a necessary order in which things must be built. I don’t just think this is OK, but encourage you to write this way. It may drum up negative emotions based on the last agile development book you read where you’re never supposed to know what you’re doing 4 months from now, but this is NOT carrying around 6 months of design and code inventory. This is a plan for the future, and it necessitates thinking about the future. What you should do is ask yourself:

1. Are we likely to get half way through this, be happy, and not want to do the rest of these requirements? 
2. If I removed requirement 5, does the strategy still work? Are any of these actually just optional?

Remember that after you deliver this strategy, and people are figuring out the specifications and designs, and customers are giving early feedback, you’ll have the opportunity to update this document. Constrain yourself and be open to interpretation from your team and customers.

The definition and measurements for success are how the strategy author is going to be held accountable for what he’s trying to rally the team to achieve. Quite often, half this work has already been achieved in previous sections. When you made the business case, you likely had a goal in mind. When you defined the necessary requirements, you likely implied somewhere that these were going to make some engagement number somewhere go up. Good job. Now you have to gather those up and come up with some basic metrics (some people call these KPIs or key-performance-indicators). It’s again important that you operate these definitions and metrics at the correct layer of abstraction and not, say, attempt to put a specific measurement behind every requirement you’ve laid out. That will happen! Hang in there! But not until later in the discovery phase. Here you want to say things like:

• New monthly customer acquisition increases 20% compared to last year’s average.
• ARR will increase 25% compared to last year.
• Customer retention will increase 50% compared to last year’s average.

Which leads to:

• Profitability in X month or quarter.

Other metrics will be built and measured at later stages of our process–where what we build will need to be tracked and scored. But here, we deal with those top level things that relate to our top level goals. What will live outside of the strategy document is the instrumentation to measure these things, which is of course necessary.

While this covers the essentials of a good strategy artifact, there are other things you can do to help the process of creating it or in creating other artifacts that are also valuable to the team. You could for instance, write an imaginary blog post. This was popularized by Amazon CTO Werner Vogels in a 2006 blog post titled: Working Backwards. It’s a very quick read. Go do that real fast…

Now just focus on point 1, which in this case, was the novel part of Amazon’s strategic process: Start by writing the Press Release.

To be clear, I don’t always do this or necessarily encourage people to write the blog post first. However it can be a useful way to get over writer's block, or to provide a roadmap for the very essential things you want to include in a strategy document. Most press releases don’t get into excruciating detail about every single thing a product does, it typically highlights the most differentiating or exciting things a product does. Those will often be the same things as your necessary requirements. But that is just a happy accident. The most powerful thing about starting with the blog post might be that it forces you to speak directly to the customer as your first action. The customer is front and center, and you are selling them on why they are going to use, buy, integrate your new thing. 

This does not replace the need for something like the strategy document we defined above, but can be a great tool for the author, or a motivating read for anyone who is working on executing the strategy.

Validation of Think, Then Do

Everything we do on a software development team needs to be in service of some strategy. There are different types of strategies: company, product, technical, but they all end up looking close to what I described above. 

I can already hear the pedants: I’m just refactoring code, I don’t need a strategy document to tell me what to do.

WRONG. Why are you paying down code debt? What is wrong with the code? What do you want to do that you can’t? What is vulnerable, and what does safety look like? Making code better is not why we pay down debt and refactor code. We do it to be safer, faster, open up new product possibilities and make future development more sane for our peers. There’s a strategic reason for everything we do in software development. 

Any company or product that I work on, or that you work on, is way too important for us to just guess our way through the days. The validation of thinking, then doing, will become more apparent in the lower levels of abstraction: discovery, building, quality assurance, and delivery. Those phases have their own challenges, enough so that questionable strategy will wreak havoc on the productivity of anyone working in those phases. So you’ll feel the initial validation by getting a team aligned, but the real payoff comes when you beat your expectations on time/cost and customer satisfaction by having an opinion on how you build things.

Next Up…

We’ve established what a good strategy looks like and we’re ready to move on to Invariant 2: Don’t don’t design without a strategy.

If you like my writing, I accept tips via Zaprite, which makes bitcoin payments easy. It's the product I'm working on these days.