Jacob Jolibois on low-floor high-ceiling products, AI PM tasks, and flattening complexity curves

Product State Q&A

Jacob Jolibois is the co-founder and Chief of Product at Check. He was formerly a Principal at MESH, and a co-founder at Parachute.fm.
Website / LinkedIn

EC: What’s the right way to build a low-floor, high-ceiling product?

JJ: The idea of low floors and high ceilings simply means that there’s a low barrier to entry but enormous potential within a product.

One of the classic examples is Microsoft Excel.

When you open a new spreadsheet, it doesn’t take a rocket scientist to understand what to do with a table. You can make a simple list or even throw some headers in there and plot items on an XY axis. But as we all know, that’s barely scratching the surface of what Excel is capable of. Fortune 500 companies are run on Excel spreadsheets! Typing a simple equal sign is enough to unlock a whole world of possibilities in a single cell.

Products with low floors and high ceilings have found a balance between an obvious first step that makes the product feel deceivingly simple — and a suite of powerful features under the hood. Users get to discover so much as they explore the product.

So what does this mean in the world of product?

• A low floor often correlates with low ‘Time to Value’ — which is simply the amount of time it takes a user to experience some value after interacting with the product for the first time.

• And a high ceiling correlates with high retention because as the user discovers more about the product and what it’s capable of, they’re less likely to leave in search of something else.

Practically speaking, there’s no ‘right’ way to build products with low floors and high ceilings, especially since each company or product team has their own way of working. However, I believe the best place to start is by identifying your ‘Clear One Thing.’ What is the single action that you want a user to take? Put that front and center — and clear a distraction-free path to it.

EC: What tasks do you see AI handling for PMs in the near future?

JJ: In the past, technology has always been the fastest moving part of society with new products and new technological breakthroughs happening every year. But AI is evolving at a pace that’s measured not in years, but in weeks — sometimes days.

So I can only speak to what AI is good at today, and not what it might be good at a year from now.

And what are present-day AIs uniquely good at? They’re good at synthesizing information within a set of guardrails.

For PMs, there are a mountain of tasks that fit this description.

• Give AI a PRD and it can break it up into the appropriate issues and plot it out on a timeline.

• Give AI a spreadsheet of user feedback and it can identify the common ideas and rank them by urgency and difficulty.

• Give AI a data structure and it can write complex queries against it.

• Give AI a data set to analyze and it can extract patterns that we might never see.

• Give AI a thesis and it'll make the opposing case to help you reason through your position.

• Give AI a rough draft and it'll polish it in the style of the company's persona.

A common reaction to this might be fear that AI will replace PMs. However, I don’t think this will be the case entirely. Rather, I believe AI will augment a PM’s capabilities, allowing them to do more than they ever could before, freeing them up to focus on product strategy, team alignment and business opportunities that require a bit more judgement and creativity.

EC: How can product teams flatten the complexity curve?

JJ: All products have some level of inherent complexity. It’s a concept known as 'Tesler’s Law. And humans are pretty great at processing a decent amount of complexity. But at some point, the complexity begins to turn into confusion. That’s what the Product Complexity Curve attempts to illustrate.

It’s a simple graph with ‘Potential for Confusion’ on the vertical axis and ‘Flexibility & Functionality’ on the horizontal axis. As you progress from left to right along ‘Flexibility & Functionality,’ the ‘Potential for Confusion’ goes up.

Since humans can process some amount of complexity before the confusion part kicks in, it’s not linear. It’s gradual at first — and then all of the sudden it begins to rise dramatically.

So as product builders, we want to slow down our rise in ‘Potential for Complexity’ as much as possible so we can continue to add ‘Flexibility & Functionality’ for a while before we start to overwhelm our users.

How do we do this? Well, as Larry taught us, complexity cannot be eliminated, only transferred or transformed. Kind of like energy. We can transfer it to people or technology — or transform it into something entirely different.

Here are a few examples:

• We can shift a user’s perception of the complexity by transferring it to the marketing or sales team. They can craft the messaging around the product and can reposition the complexity as power or job security.

• We can help a user understand the complexity by transferring it to the customer support/success team. As they understand the product more, the complexity drops and opens up more room to learn something new.

• We can make it easier for a user to digest the complexity by transferring it to the design team. A great user interface can hide some of the complexity or reveal it in chunks so the user isn’t hit with it all at once.

• We can abstract the complexity away by transferring it to the engineering team. Sometimes, the complexity can be entirely handled by the code. Of course writing that code takes time, but it reduces the burden on the user.

• We can make the complexity worth it by transforming it into value. If something complex unlocks tremendous value, it becomes worth the effort.

There are, of course, more ways you can transfer and transform complexity, but I hope these have given you some examples to riff on.

“What is the single action that you want a user to take? Put that front and center — and clear a distraction-free path to it.”
- Jacob Jolibois