Capability, Usability & Utility

Dear Michael,

I love the concept of the format. I’m in. Common wisdom is that starting is hard. I think it’s true but I think finishing is much harder! Let’s try and do both.

I wanted to talk about the different dimensions we need to move our product in. What came out when I started to write it wasn’t what I had in mind at all. I’ll shelve that for another day when the ideas are more fully formed. So bear in mind I reserve the right to redefine product dimensions as something else in a few letters time.

Capability, Usability & Utility

When we are assessing which pitches to work on I think it would be good if we could have a broader framework around which product goals those pitches are helping us with, which long term themes is the pitch helping to move the product in, i.e. which product dimensions are we moving.

We have thought about two product dimensions for years now without calling them dimensions. Those were:

• capability: the functionality, features, the power of the product to do things. What can it do?
• usability: the ease at which users can use the product. Can it be used?

They are really broad dimensions, and they’re great as they interplay with each other. The more you push on capability the harder it is to maintain high levels of usability, and conversely one of the easiest ways to get breakthrough usability is to have much less capability.

Around 6 months or so ago I introduced a third dimension which I think we’d (laughably) overlooked for sometime:

• utility: the value that can be gained from using the product. Is it useful?

Utility is a really interesting one as it is the first dimension when the market gets involved. Customers might love powerful, easy to use products but they won’t if they don’t provide value.

Target States

The naive assumption here is that all of these dimensions should be maximised. That’s clearly not what we want. Firstly all of them need to be balanced against cost, and secondly we need to be opinionated and focused in deciding what problem we are trying to solve (utility) and which bits of capability we want to add to do so (capability).

The best product will not do everything, but it will do the common use cases better than anything else. Specifically, for the use cases that we target, using Stacker should be a better end user experience than using apps made in the traditional method of writing code.

We want to maximize usability (offset against cost and complexity from increased capability).

We want to minimize capability for fixed utility (if we can solve the problem with less functionality and complexity we should).

We want to maximize utility within the specific problem space we are targetting, and we want to minimize utility outside of it (we want to be focused).

Upcoming Pitches

We’ve committed to work on five items in the next batch:

• Serious Platform: levelling up our infrastructure & monitoring so we are ready to scale (increase in usability).
• Different Data Sources: adding support for Salesforce & SQL data sources (same capability but now for new markets gives an increase in utility).
• Richer Apps: new functionality to make apps more powerful (increase in capability).
• Mobile First: make the output of Stacker work really well on mobile (increase in utility).
• Improved Airtable Cache: better cache invalidation for customers using large base support (increase in usability).

I must say the way that capability and utility are so tightly coupled does maybe make it better to group them.

On Blogging

We definitely need a name. Here are some suggestions:

• Dear Founder
• Stacker Letters
• Stack of Letters
• Stacked Up
• Under the Stack
• Oh Founder!
• Open Stacker
• Startup Letters
• Founder Letters

I am not sure that Stacker needs to be in the name. My vote is probably with Oh Founder!

Cheers,

Sam