1. Writing >
2. A decision in principle

👨‍💻 Jonathan Roberts
🗓 09 June 2020
⏱ 12 minutes
🏷 Designance

A decision in principle

No.003 - Making difficult decisions easy

It seems almost inappropriate to be narrowly focused on subjects like design and finance at the moment. When I sit down to write I get the feeling I should be doing something more useful. So I read instead and wait until I’m ready to write again. Maybe that’s why I’m some way behind my aim of putting this out once a month.

I’ve been reading about the future; about how people without domain expertise accurately predict future events¹, articles from people who have actually done that², and speculation about the future of work:

people will belong to multiple organisations and entities over time and at any one time, with the equivalent of equity in each, and possibly drawing annuity streams from them either as a worker or a member, sharing data. _David Galbraith via Exponential View

This caught my attention because it taps into the reason I’m working on this project – whether it’s building a product of my own, and/or buying shares – which is to make an investment now in return for an income in the future.

Drawing “annuity streams” from multiple sources isn’t a new idea for some – take people who own shares in companies and receive meaningful dividends, for example – but it will be for others (like the full time employees of those companies).

Will this change? It certainly seems feasible. Companies are taking a heavy and potentially protracted hit to their revenue. Organisations who might usually expect to compensate you in cash for 100% of your time may have to consider the prospect of instead compensating you with future returns for a smaller proportion of your time.

Whether the pandemic produces a seismic shift in the nature of work and compensation – or not – it’s useful motivation to continue with this project.

☕️ 10 minute read

The making of a principle

I’m writing Designance as I pitch my investing skills against my ability to build a product from scratch. It’s my experiment to understand whether I can get a better return from investing my cash in company shares, or by building a product company of my own.

Today I’m thinking about the role of principles in decision making.

Projects make progress when the people working on them are able to make good quality decisions quickly. In my experience, the people most capable of doing this have one thing in common; they have absolute clarity of their principles.

With clear principles, decisions don’t feel like decisions at all, more like just the right thing to do.

And it’s a lot easier said than done because at some point a decision based on a principle will cost you – in time, or money, or reputation – and that’s when you’ll discover if it really was a principle in the first place.

When a solo-founder I know first started charging for software he’d developed, he made some decisions that seemed counterintuitive.

The product was extensively used in commercial organisations and one of the first paid features was “Support”. Anyone who’s ever developed B2B software knows that support is a valuable feature. It’s a feaute that companies will happily pay for, and that happens to be the easiest to provide without development effort.

I don’t know what your experience of enterprise organisations is, but I tend to think of them as needing answers yesterday. So it seemed odd to me that the solo-founder of this product would introduce the support feature and then choose to make the service level agreement (SLA) “2 business days by email”. Surely immediately by phone would be more attractive?

The decision was simple, like the principle behind it; work-life balance. The principle was valuing the option to take a long weekend snowboarding without the need to answer support emails from the top of a mountain.

The cost of this principle may well have been revenue. It’s hard to know how many people read “2 business days by email” and walked away. But what’s the point in working hard to build a product or company if it can’t repay you with more time to do what you love?

Ultimately it didn’t matter. The work-life balance principle was complemented by a second; that the product be robust and reliable. When the product performed first time every time, its reputation for reliability offset the risk the first principle introduced and more paid features followed.

Thinking about my own principles

1. Avoid advertising

The first principle I have is to avoid investing (be it in shares or time developing a product) in anything that relies on advertising for revenue³.

Advertising warps product design decisions. When revenue isn’t coming from the people using your product, there’s less drive to do right by them⁴.

Put another way:

“Advertising is a tax the poor and technologically illiterate pay”, Scott Galloway, No Mercy / No Malice

YouTube have begun pushing their paid-subscription tier on the value proposition of an ad-free experience. It’s £12 per month!

YouTube adverts are so closely tied to my experience of videos on that platform that it’s not clear to me what’s left if you remove them. Regardless, it is clear that for those who can’t pay to remove them - at twice the cost of Netflix - it is a tax.

2. Products over services

If I’m going to invest my time or money in something, I also believe that something should be a product and not a service. This is my second principle.

A well-designed product codifies the knowledge of the person (or people) that produced it, and delivers it as something that can be replicated and distributed to lots of people at the same time.

A service – according to my narrow-definition, at least – relies on the presence of the people with specific knowledge. Consultancy is a simple example of this. Yes, it can be high-margin, but it’s hard to do from the top of a mountain and customers can easily choose to switch it off when it’s time to cut costs.

(Of course, the magic of software means that it can often achieve the quantum state of being both a product and a service at the same time.)

3. Favour process

My third principle comes from ten plus years spent trying to understand what makes a good product successful. I think the key is not losing sight of the system in which your product is being used.

There is a tendency for people to obsess over their tools - writing apps, programming languages, design software etc. The tendency extends the other way towards producers of those products.

Being a good, carefully designed product for a specific individual – like “As an X I want to do Y”, and even “Jobs-to-be-done” – still won’t protect you from failure. Trust me, I’ve designed a few of these.

The most successful products I’ve seen care as much about being critical to a process or system as they do about being tailored to the needs of the individual.

4. Worth charging for

The companies whose shares you can buy (usually) have this worked out in advance of going public, so this principle might seem obvious and therefore extraneous.

I’ve chosen to call it out as a principle in helping my decision making as I construct the idea of what sort of product I might want to create. After all, a future income stream is the purpose of this project.

You have to charge $50-$500/mo, and make something of genuine value, Jason Cohen, asmartbear.com

Were I to create a product based on that advice then, my suspicion is that it’d need to be for people in commercial/enterprise settings. This is in part because of the price point, but also because it fits with the “Favour process” principle above.

Patrick McKenzie’s thoughts appear to back this up:

$50 is a much better minimum buy-in for most B2B services than $20 is. You'll make a lot more money, sure, but you'll enjoy the reduced support headaches and vastly lower churn even more. https://t.co/XD4Lvek5x8

— Patrick McKenzie (@patio11) May 15, 2020

5. Make it myself

I think my last principle (for now) is likely to be my most controversial. Should I create a product, it should be something I can build and own myself as a solo-founder – at least until I can no longer grow it to whatever it needs to be.

This is in part because most of the successful⁵ start-ups I’ve met have been run by solo-founders. It’s also because I get enough collaboration and influence practice in my day job.

I have two contrasting views on this already, and I expect this principle to be the one that gets tested the most because:

1. The people who advocate most strongly for co-founders are Venture Capitalists. Of the ones I’ve met, none would entertain the idea of investing in a solo-founder. My assumption for that preference is that co-founders somehow half the risk of an already risky investment⁶.
2. The people who have started companies as co- or multi-founders have repeatedly told me that it’s nice to be able to experience the ride together; support through the lows and shared celebration of the highs.

So, to recap:

Principles for investing 

1. Don't invest in business models based on advertising
2. Favour products over services - probably software
3. The product must be worth charging for
4. Favour products that work within a shared process
5. Build and own it myself, until I can't grow it further

Modern product design is MIA

A few weeks ago a designer friend of mine and I were catching up. I was looking for help with a design problem I faced – or more specifically, a design problem that I was unable to face.

For the past three years I’ve been working on products for software developers. Not once in that time has a designer shown (to me at least) any interest in designing for these products.

Developer tools are typically driven by a Command Line Interface (CLI). If you grew up in the early nineties you might recognise them from having had to type “win” in MS-DOS to launch Microsoft Windows 3.1.

So what makes these hard to design for?

A Graphical User Interface (GUI) makes a computer comprehensible by enabling you to build a conceptual model of how it works (buttons, folders etc). Except what the GUI actually does is to create an abstraction from how the thing actually works. You can test this with this assertion: just because you can use a computer, it doesn’t mean you can program one.

Since a CLI provides very few (obvious) cues as to how the system works, my assumption was that CLIs are interpreted as being complex.

What I was looking for from my friend was a recommendation for a tool, or a process that would help a user experience designer develop their comprehension of a CLI; or any complex product.

We talked it over, and I even went so far as to try to describe the problem as I saw it, in much more detail. I did this partly to help my thinking, but mainly because I remembered that, in marketing, the problem is more interesting than the product.

Having thought about it more since, I don’t believe CLI products are that complex to design for. At least not once you understand the near-universal patterns and paradigms they employ. What is complex about them is the systems in which they tend to function.

Command-driven products can be incredibly flexible. Instead of one GUI being jabbed at by a user with a monitor and a mouse, these products can be controlled by humans, or other software, or even via a response to data.

With this framing I can see other products fall into the same category – protein analysis machines, social media platform algorithms – and I realise now what’s needed is a tool, or a process that would help a user experience designer develop their comprehension of a complex system.

Now we’re getting somewhere. Systems theory is its own field of study. Perhaps the answer to the to this missing design software can be found there, but it’s going to take some research.

And that’s going to require persistence and habit forming.

Reading list

Some of the artilces that have caught and consumed my attention over the past month:

• ☕️ PJH describes Modernism a design’s post-war break from the past and wonders is this “an opportunity to start a new movement”
• ☕️ Patrick MacKenzie describes using a hash to publish his prediction about the scale of epidemic in Japan, without making that prediction public until he was ready in “A pre-registered result about the corona virus”
• ☕️ Bill Gates talks pandemic innovation and gives a coherent description of where we are right now
• 📚 Superforecasting: The Art and Science of Prediction by Philip E. Tetlock, Dan Gardner
• 🎧 Philip E. Tetlock on Forecasting and Foraging as a Fox (YouTube / Podcast)
• 💼 Two hundred and fifty things an architect should know

Footnotes

© Jonathan Roberts 2020
I occasionally update articles to fix typos, improve readability or modify content when new information is available to me: view revisions for this article