Archive of posts with tag 'Jobs To Be Done'

On Validating Product Ideas

January 19, 2023 • #

Building new things is an expensive, arduous, and long path, so product builders are always hunting for means to validate new ideas. Chasing ghosts is costly and deadly.

The “data-driven” culture we now live in discourages making bets from the gut. “I have a hunch” isn’t good enough. We need to hold focus groups, do market research, and validate our bets before we make them. You need to come bearing data, learnings, and business cases before allowing your dev team to get started on new features.

And there’s nothing wrong with validation! If you can find sources to reliably test and verify assumptions, go for it.

But these days teams are compelled to conduct user testing and research to vet a concept before diving in.

This push for data-driven validation I see as primarily a modern phenomenon, for two reasons:

First, in the old days all development of any new product was an enormously costly affair. You were in it for millions before you had anything even resembling a prototype, let alone a marketable finished product. Today, especially in software, the costs of bringing a new tool to market are dramatically slashed from 20 or 30 years ago. The toolchains and techniques developed over the past couple decades are incredible. Between the rise of the cloud, AWS, GitHub, and the plethora of open source tools, a couple of people have superpowers to do what used to take teams of dozens, and thousands of hours before you even had anything beyond a requirements document.

Second, we have tools and the cultural motivation to test early ideas, which weren’t around back in the day. There’s a rich ecosystem of easy-to-use design and prototyping tools, plus a host of user testing tools (like UserTesting, appropriately) to carry your quick-and-dirty prototypes out into the world for feedback. Tools like these have contributed to the push for data-driven-everything. After all, we have the data now, and it must be valuable. Why not use it?

I have no problem with being data-driven. Of course you should leverage all the information you can get to make bets. But data can lie to you, trick you, overwhelm you. We’re inundated with data and user surveys and analytics, but how do we separate signal from noise?

One of my contrarian views is that I’m a big defender of gut-based decision making. Not in an “always trust your gut” kind of way, but rather, I don’t think listening to your intuition means you’re “ignoring the data.” You’re just using data that can’t be articulated. It’s hard to get intuitive, experiential out of your head and into someone else’s. You should combine your intuitive biases with other objective data sources, not attempt to ignore them completely.

I’m fascinated by tacit knowledge (knowledge gained through practice, experience). It differentiates between what can be learned only through practice from what can be read or learned through formal sources — things we can only know through hands-on experience, versus things we can know from reading a book, hearing a lecture, or studying facts. Importantly, tacit knowledge is still knowledge. When you have a hunch or a directional idea about how to proceed on a problem, there’s always an intrinsic basis for why you’re leaning that way. The difference between tacit knowledge and “data-driven” knowledge isn’t that there’s no data in the former case; it’s merely that the data can’t be articulated in a spreadsheet or chart.¹

I’ve done research and validation so many ways over the years — tried it all. User research, prototype workshopping, jobs-to-be-done interviews, all of these are tools in the belt that can help refine or inform an idea. But none of them truly validate that yes, this thing will work.

One of the worst traps with idea validation is falling prey to your own desire for your idea to be valid. You’re looking for excuses to put a green checkmark next to an idea, not seeking invalidation, which might actually be the more informative exercise. You find yourself writing down all the reasons that support building the thing, without giving credence to the reasons not to. With user research processes, so many times there’s little to no skin in the game on the part of your subject. What’s stopping them from simply telling you want you want to hear?

Paul Graham wrote a post years ago with a phenomenal, dead-simple observation on the notion of polling people on your ideas. A primitive and early form of validation. I reference this all the time in discussions on how to digest feedback during user research (emphasis mine):

For example, a social network for pet owners. It doesn’t sound obviously mistaken. Millions of people have pets. Often they care a lot about their pets and spend a lot of money on them. Surely many of these people would like a site where they could talk to other pet owners. Not all of them perhaps, but if just 2 or 3 percent were regular visitors, you could have millions of users. You could serve them targeted offers, and maybe charge for premium features.

The danger of an idea like this is that when you run it by your friends with pets, they don’t say “I would never use this.” They say “Yeah, maybe I could see using something like that.” Even when the startup launches, it will sound plausible to a lot of people. They don’t want to use it themselves, at least not right now, but they could imagine other people wanting it. Sum that reaction across the entire population, and you have zero users.

The hardest part is separating the genuine from the imaginary. Because of the skin-in-the-game problem with validation (exacerbated by the fact that the proposal you’re validating is still an abstraction), you’re likely to get a deceitful sense of the value of what you’re proposing. Would you pay for this? is a natural follow up to a user’s theoretical interest, but is usually infeasible at this stage.

It’s very hard to get early critical, honest feedback when users people have no reason to invest the time and mental energy thinking about it. So the best way to solve for this is to reduce abstraction — give the user a concrete, real, tangible thing to try. The closer they can get to a substantive thing to assess, the less you’re leaving to their imagination as to whether the thing will be useful for them. When an idea is abstract and a person says “This sounds awesome, I would love this”, you can safely assume they’re filling in unknowns with their own interpretation, which may be way off the mark. Tangibility and getting hands-on with a complete, usable thing to try, removes many false assumptions. You want their opinion on what it actually will be, not what they’re imagining it might be.

In a post from a couple years ago, Jason Fried hit the mark on this:

There’s really only one real way to get as close to certain as possible. That’s to build the actual thing and make it actually available for anyone to try, use, and buy. Real usage on real things on real days during the course of real work is the only way to validate anything.

The Agile-industrial complex has promoted this idea for many years: moving fast, prototyping, putting things in market, iterating. But our need for validation — our need for certainty — has overtaken our willingness to take some risk, trust in our tacit knowledge, and put early, but concrete and minimal-but-complete representations out there to test fitness.

De-risking investments is a critical element of building a successful product. But some attempts to de-risk actively trick us into thinking an idea is better than it is.

So I’ll end with two suggestions: be willing to trust your intuition more often on your ideas, and try your damnedest to smoke test an idea with a complete representation of it, removing as much abstraction as possible.

I’d highly recommend Gerd Gigerenzer’s book Gut Feelings, which goes deep on this topic. For a great précis on the topic, check out his conversation from a few years back on the EconTalk podcast. ↩

✦

How to Think About Your Competitors

October 10, 2022 • #

For any company, keeping track of your position in the competitive landscape is an important element of making the right decisions. When I think about competitors, I think about them separately as “direct” vs. “indirect”:

Direct competitor: one with a product offering highly similar and seen by your customer as a direct substitute
Indirect competitor: one that might look glancingly similar (or very different) on the surface, but addresses the same jobs to be done

Direct vs. indirect doesn’t matter all that much at the end of the day; you’re still trying to occupy the same problem space for your target audience. The important piece is to remember that it should be inclusive of the indirect: those that obliquely address the same concern for a user.

The big question is: how much time and attention should you spend on monitoring and analyzing your position relative to your competitors? Clearly the right answer lies somewhere on the spectrum between none and way too much.

It’s commonplace to skew too far to the left or right on this spectrum — to either be too concerned with the day-to-day movement of what your competitors are doing, or to have too much confidence in your own position, willfully ignoring what your competitors or the market are doing. On one end you can’t stop worrying about it every time a customer mentions a competing product’s features. On the other, you’re saying “we have no competition.”

Clearly the right answer is somewhere in the center, taking behaviors from each side and combining them in creative ways to do something unique, but with enough similarity to the market that you can sell the future you’re building with minimal friction.

What if we could think about “competitive attention” on a spectrum? The spectrum could go from:

Zero attention on competitors or the market, to
Spending all of your time worried about and analyzing what competitors are doing

Broadly speaking, moving along each direction of the spectrum trends toward being more of a leader or a follower. Leaders blaze their own path and drive toward a vision of the future they define. Followers can’t stop chasing what someone else is doing. It might sound like I’m making the case for “leader” here — after all, leader has the positive connotation, and follower makes you sound like an also-ran. But there are plenty of areas in all businesses where it’s smart to conform to market norms rather than trail-blazing. You should make sure your unique, innovative edge is concentrated in specific areas. Even world-changing product innovators don’t completely ignore what existing markets look like of course.

The best companies view the world from a demand perspective (What do customers want? What are the jobs to be done?) rather than a supply one (Who is building what in the market?)

Let’s define a spectrum, and some points along it:

Definitions on the spectrum — the left side leans toward independence (with an extreme of brazen ignorance), the right toward paranoia (some is a healthy thing, but in the extreme, it’s obsession):

Independent mindset:
- ⟽ Willful Ignorance — You’re irrationally overconfident in your market position. You intentionally don’t care what competitors are doing, you denigrate other options or solutions as irrelevant or obsolete, and you believe you’re more important to your customer than you are. “We could never be replaced” (You can definitely be replaced).
- ⟻ Blissful Naiveté — You don’t go so far as to think you’re invincible, but you have an ignorance of the market due to naiveté more than overconfidence. You don’t bother to spend the time to understand the landscape you participate in.
- ⭐️ Creative Confidence — The ideal place to be. Confident in your own ideas, maintaining the ability to design and build solutions independently of what others in the market are doing. You focus on creating from first principles based on customer demand, not on copying what others do.
Paranoid mindset:
- ⟾ Dangerous Obsession — You let competitors dominate your thinking, constantly worried that every new one you discover is already eating your lunch. You call meetings and have big discussions about what competitors are doing, in the worst cases moving your own goalposts continuously when competitors make movements. Instead of worrying about how to solve your current customers’ problems and inventing new solutions for them, you’re spend all your time looking for a customer you don’t have. The grass is always greener somewhere else.
- ⟼ Frequent Distraction — You do spend time with your own customers looking at what you can build for them, but you let what other people are building distract you from the time required to build truly novel product. Monitoring others’ feature lists and building comparison matrices steals away enough attention to slow you down in your new creative efforts. You pull punches on your innovative work because you’re scared to step too far off a well-trod path. Keeping up with what’s in the rearview steals away your attention from solving your current customer’s problems.
- ⭐️ Informed Balance — You’re knowledgable about the market and its players, but not in a way that keeps you up at night. you have a confident, informed understanding of what other players can do, and you spend most of your time in “competitive” headspace thinking about articulating your differentiation. Because you’re out in front building your own thing, people copy you more than the other way around. But you do maintain just enough useful paranoia to temper your overconfidence.

It takes willful effort to position your mind in the right spot on the line. And depending on the situation, pushing your view left or right is defensible. In some areas you shouldn’t care what the competition is doing — dare to solve the problem differently. In other cases, not all things you need to build are key differentiators; some things are simply table-stakes things that need doing. Innovation and creativity are expensive. You want to spend those resources where they count.

✦

Jobs Clubhouse Does

February 23, 2021 • #

If you’re on the internet and haven’t been living under a rock for the last few months, you’ve heard about the startup Clubhouse and its explosive growth. It launched around the time COVID lockdowns started last year, and has been booming in popularity even with (maybe in-part due to?) an invitation gate and waitlist to get access.

The core product idea centers around “drop-in” audio conversations. Anyone can spin up a room accessible to the public, others can drop in and out, and, importantly, there’s a sort of peer-to-peer model on contributing that differentiates it from podcasting, its closest analog.

I got an invite recently and have been checking out sessions from the first 50 or so folks I follow, really just listening so far. Their user and growth numbers aren’t public, but from a glance at my follow recommendations I see lots of people I follow on Twitter already on Clubhouse.

They recently closed a B round led by Andreessen Horowitz, who also backed the company in its earlier months last year. Any time an investor does successive rounds this quickly is an indicator of magic substance under the hood, signals that show tremendous upside possibility. In the case of Clubhouse, user growth is obviously a big deal — viral explosion this quickly is always a good early sign — but I’m sure there are other metrics they’re seeing that point to something deeper going on with product-market fit. Perhaps DAUs are climbing proportional to new user growth, average session duration is super long, or retention is extremely high (users returning every day).

On the surface a skeptical user might ask: what’s so different here from podcasts? It’s amazing what explosive growth they’ve had given the similarities to podcasting (audio conversations), and considering its negatives when compared with podcasts. In all of the Clubhouse rooms I’ve been in, most users have telephone-level audio quality, there’s somewhat chaotic overtalk, and “interestingness” is hard to predict. With podcasts you can scroll through the feed and immediately tell whether you’ll find something interesting; when I see an interesting guest name, I know what I’m getting myself into. You can reliably predict that you’ll enjoy the hour or so of listening.

Whenever a new product starts to take off like this, it’s hitting on some aspect of latent user demand, unfulfilled. What if we think about Clubhouse from a Jobs to Be Done perspective? Thinking about it from the demand side, what role does it play in addressing jobs customers have?

Clubhouse’s Differentiators

Clubhouse describes itself as “Drop-in audio chat”, which is a stunningly simple product idea. Like most tech innovations of the internet era, the foundational insight is so simple that it sounds like a joke, a toy. Twitter, Facebook, GitHub, Uber — the list goes on and on — none required invention of core new technology to prosper. Each of them combined existing technical foundations in new and interesting ways to create something new. Describing the insights of these services at inception often prompted responses like: “that’s it?”, “anyone could build that”, or “that’s just a feature X product will add any day now”. In so many cases, though, when the startup hits on product-market fit and executes well, products can create their own markets. In the words of Chris Dixon, “the next big thing will start out looking like a toy”.

Clubhouse rides on a few key features. Think of these like Twitter’s combo of realtime messaging + 140 characters, or Uber’s connection of two sides of a market (drivers and riders) through smartphones and a user’s current location. For Clubhouse, it takes audio chat and combines:

Drop-in — You browse a list of active conversations, one tap and you drop into the room. Anyone can spin up a room ad-hoc.
Live — Everything happening in Clubhouse is live. In fact, recording isn’t allowed at all, so there’s a “you had to be there” FOMO factor that Clubhouse can leverage to drive attention.
Spontaneous — Rooms are unpredictable, both when they’ll sprout up and what goes on within conversations. Since anyone can raise their hand and be pulled “on stage”, conversation is unscripted and emergent.
Omni-directional — Podcasts are one-way: from producer to listener, or some shows have “listener mail” feedback loops. Clubhouse rooms by definition have a peer-to-peer quality. They truly are conversations, at least as long as the room doesn’t have 8,000 people in it.

None of these is a new invention. Livestreaming has been around for years, radio has done much of this over the air for a century, and people have been hosting panel discussions since the time of Socrates and Plato. What Clubhouse does is mix these together in a mobile app, giving you access to live conversations whenever you have your phone plus connectivity. So, any time.

Through the Lens of Jobs

Jobs to Be Done focuses on what specific needs exist in a customer’s life. The theory talks about “struggling moments”: gaps in demand that product creators should be in search of, looking for how to fit the tools we produce into true customer-side demand. It describes a world where customers “hire” a product to perform a job. Wherever you see products rocketing off like Clubhouse, there’s a clear fit with the market: users are hiring Clubhouse for a job that wasn’t fulfilled before.

Some might make the argument that it’s addressing the same job as podcasts, but I don’t think that’s right exactly. For me it has hardly diminished my podcast listening at all. I think the market for audio is just getting bigger — not a zero-sum taking of attention from podcasts, but an increase in the overall size of the pie. Distributed work and the reduction of in-person interaction and events has amplified this, too (which we’ll get to in a moment, a critical piece of the product’s explosive growth).

Let’s go through a few jobs to be done statements that define the role that Clubhouse plays in its users’ lives. These loosely follow a format for framing jobs to be done, statements that are solution-agnostic, result in progress, and are stable across time (see Brian Rhea’s helpful article on this topic).

I’m doing something else and want to be entertained, informed, etc.

Podcasts certainly fit the bill here much of the time. Clubhouse adds something new and interesting in how lightweight the decision is to jump into a room and listen. With podcasts there’s a spectrum: on one end you have informative shows like deep dives on history or academic subjects (think Hardcore History or EconTalk) that demand attention and that entice you to completionism, and on the other, entertainment-centric ones for sports or movies, where you can lightly tune in and scrub through segments.

The spontaneity of Clubhouse rooms lends well to dropping in and listening in on a chat in progress. Because so many rooms tend to be agendaless, unplanned discussions, you can drop in anytime and leave without feeling like you missed something. Traditional podcasts tend to have an agenda or conversational arc that fits better with completionist listening. Think about when you sit down with Netflix and browse for 10 minutes unable to decide what to watch. The same effect can happen with podcasts, decision fatigue on what to pick. Clubhouse is like putting on a baseball game in the background: just pick a room and listen in with your on-and-off attention.

Ben Thompson called it the “first Airpods social network”. Pop in your headphones and see what your friends or followers are talking about.

I have an idea to express, but don’t want to spend time on writing or learning new tools

Clubhouse does for podcasting what Twitter did for blogs: massively drops the barrier to entry to participation. Setting up a blog has always required some upstart cost. Podcasting is even worse. Even with the latest and greatest tools, publishing something new has overhead. Twitter lowered this bar, only requiring users to tap out short thoughts to broadcast them to the world. Podcasting is getting better, but is still hardware-heavy to do well.

There’s a cottage industry sprouting up on Clubhouse of “post-game” locker room-style conversations following events, political, sports, television, even other Clubhouse shows. This plays well with the live aspect. Immediately following (or hell, even during) sporting events or TV shows, people can hop in a room and gab their analysis in real time.

Clubhouse’s similarities to Twitter for audio are striking. Now broadcasting a conversation doesn’t require expensive equipment, audio editing, CDNs, feed management. Just tap to create a room and notify your followers to join in.

I want to hear from notable people I follow more often

This one has been true for me a few times. With the app’s notifications feature, you can get alerts when people you follow start up a room, then join in on conversations involving your network whenever they pop up. I’ve hopped in when I saw notable folks I follow sitting in rooms, without really looking at the topic. For those interesting people you follow that you make sure to listen to, Clubhouse expands those opportunities. Follow them on Clubhouse and drop in on rooms they go into. Not only can you hear more often from folks you like, you also get a more unscripted and raw version of their thoughts and ideas with on-the-fly Clubhouse sessions.

I want to have an intellectual conversation with someone else, but I’m stuck at home!

Or maybe not even an intellectual one, just any social interaction with others!

This is where the timing of Clubhouse’s launch in April of last year was so essential to its growth. COVID quarantines put all of us indoors, unable to get out for social gatherings with friends or colleagues. Happy hours and dinners over Zoom aren’t things any of us thought we’d ever be doing, but when the lockdowns hit, we took to them to fill the need for social engagement. Clubhouse fills this void of providing loose, open-ended zones for conversation just like being at a party. Podcasts, books, and TV are all one-way. Humans need connection, not just consumption.

COVID hurt many businesses, but it sure was a growth hack for Clubhouse.

Future Jobs to Be Done?

Products can serve a job to be done in a zero- or positive-sum way. They can address existing jobs better than the current alternatives, or they can expand the job market to create demand for new unfulfilled ones. I think Clubhouse does a bit of both. From first-hand experience, I’ve popped into some rooms in cases when I otherwise would’ve put on a podcast or audiobook, and several times when I was listening to nothing else and saw a notification of something interesting. Above are just a few of the customer jobs that Clubhouse is filling so far. If you start thinking about adjacent areas they could experiment with, it opens up even more greenfield opportunity. Offering downloads (create a custom podcast feed to listen to later?), monetization for organizers and participants (tipping?), subscription-only rooms (competition with Patreon?). There’s a long list of areas for the product to explore.

Where Does Clubhouse Go Next?

There’s a question in tech that’s brought up any time a hot new entrant comes on the scene. It goes something like:

Can a new product grow its network or user base faster than the existing players can copy the product?

This has to be at the forefront of the Clubhouse founders’ minds as their product is taking off. Twitter’s already launched Spaces, a clone of Clubhouse that shows up in the Fleets feed. That kind of prominent presentation to Twitter’s existing base adds quite the competitive threat, though Twitter isn’t known for it’s lightning-quick product innovation over the last decade. But maybe they’ve learned their lesson in all their past missed opportunities. What could play out is another round of what happened to Snap with Stories, a concept that’s been copied by just about every product now.

Clubhouse is doing a respectable job managing the technical scalability of the platform as it grows. The growth tactics they’re using with pulling in contacts, while controversial, appear to be helping to replicate the webs of user connections. The friction in building new social interest graphs is one of the primary things that’s stifled other social products over the last 10 years. By the time new players achieve some traction, they’re either gobbled up by Twitter or Facebook, or copied by them (aside from a few, like TikTok). Can Clubhouse reach TikTok scale before Twitter can copy it?

There are still unanswered questions on how Clubhouse’s growth plays out over time:

How far can it reach into the general public audience outside of its core tech-centric “online” crowd?
Like any new network-driven product, when it’s shiny and new, we see a gold rush for followers. What behaviors will live chat incentivize?
How will room hosts behave competing for attention? What will be the “clickbait” of live audio chat?
What mechanisms can they create for generating social capital on the network? How does one build an initial following and expand reach?

Right now, the easiest way to build a following on Clubhouse is just like every other social network’s default: bring your already-existing network to the platform. It’s a bit early to see how Clubhouse might address this differently, but most of the big time users were folks with large followings on Twitter, YouTube, or elsewhere. It’d be cool to see something like TikTok-esque algorithm-driven recommendations to raise distribution for ideas or topics even outside of the follower graphs of the members of the rooms.

Clubhouse (and this category of live multi-way audio chat) is still in the newborn stages. As it matures and makes its way to wider audiences outside of mostly tech circles, it’ll be interesting to see what other “jobs” are out there unfilled by existing products that it can perform.

✦

Weekend Reading: Liberal Science, Roam42, and JTBD Examples

February 6, 2021 • #

🧠 In Defense of Being Offensive

Jonathan Rauch on pluralism and the necessity of disagreement in the search for truth.

His book Kindly Inquisitors was first published in 1993, but is as relevant today as ever. The book is a defense of what he calls “liberal science”, our decentralized process for knowledge discovery that relies on relentless-but-gradual error correction:

Liberal science, by its very nature, has little tolerance for fundamentalism; conversely fundamentalism is a threat to liberal science. Fundamentalism, defined by Rauch as the “search for certainty rather than for errors,” is the antithesis of scientific inquiry. Fundamentalism seeks a monopoly on knowledge from which it can deny the beliefs put forth by all others. Rauch even notes that there are fundamentalist free-marketeers—those who refuse to accept the possibility that cherished economic axioms may be flawed, or at least in need of revision—and he challenges them to enhance their intellectual rigor. If classical liberals are willing to accept the self-correcting actions of the marketplace to properly allocate valued resources, they should also allow the self-correcting mechanisms of liberal science to separate knowledge from supposition.

Due to its nature as a decentralized system, liberal science frees knowledge from authoritarian control by self-appointed commissars of truth. “In an imperfect world, the best insurance we have against truth’s being politicized is to put no one in particular in charge of it,” notes Rauch. Liberal science achieves this end. It avoids despotism in the intellectual realm as it does in those of politics and economics.

⌨️ Become a Keyboard Pro with Roam42

A great guide here from Ramses at RoamStack

I set up RoamHacker’s Roam42 suite for SmartBlocks a few weeks back, and it’s game-changing. I’m still a novice with it and have only used a few of its tools, but this sort of extensibility and programmability is what’s making Roam the most interesting text platform.

👨‍💻 How to Write Jobs to Be Done Example Statements

This is a solid, brief guide on how to frame Jobs to Be Done statements.

“Help me brush my teeth in the morning” is not a great example of a Job to Be Done statement.

“Help me brush my teeth in the morning” is joined at the hip to an existing solution (a toothbrush) and there’s only so far you’ll be able to expand your thinking within that bubble.

A way to describe the Job to Be Done when a person is brushing their teeth that could lead to more innovative product design is:

“Keep my teeth healthy.”

✦

Weekend Reading: American Growth, JTBD, and Dissolving the Fermi Paradox

October 17, 2020 • #

📉 Summary of The Rise and Fall of American Growth

Concise summary of Robert Gordon’s book on Roots of Progress.

👨🏻‍🏫 Guide to Jobs to be Done Interviews

A solid comprehensive, step-by-step overview of how to conduct JTBD interviews.

🛸 Dissolving The Fermi Paradox

A pointer somewhere on Twitter led to this post from the Slate Star Codex archives, discussing a paper that supposedly debunks the Fermi paradox:

Imagine we knew God flipped a coin. If it came up heads, He made 10 billion alien civilization. If it came up tails, He made none besides Earth. Using our one parameter Drake Equation, we determine that on average there should be 5 billion alien civilizations. Since we see zero, that’s quite the paradox, isn’t it?

No. In this case the mean is meaningless. It’s not at all surprising that we see zero alien civilizations, it just means the coin must have landed tails.

✦

A Nomenclature for Low-Code Users

July 7, 2020 • #

The low-code “market” isn’t really a market. Rather, I see it as an attribute of a software product, an implementation factor in how a product works. A product providing low-code capability says nothing about its intended value — it could be a product for sending emails, building automation rules, connecting APIs, or designing mobile forms.

What are termed “LCAP” (low-code application platform) software are often better described as “tools to build your own apps, without having to write all the code yourself.”

This post isn’t really about low-code as a marketplace descriptor, but about refining the nomenclature for how we talk about users we have in mind when designing low-code tools. Who are we building them for? Who needs them the most?

As Aron Korenblit wrote a few months back, low-code as a term isn’t really about code, per se, but often things like process modeling, workflows, data flows, data cleanliness, speed of prototyping, and low cost trial and error:

If what we’re trying communicate is that no-code helps get things done faster, we should elevate that fact in how we name ourselves instead of objecting to code itself.

For many years, all sorts of tools from Mailchimp or Webflow to Fulcrum or Airtable provide layers of capabilities for a continuum of user types, moving from the non-technical through to full developers. The non-tech space wants templates and WYSIWIG tools, the devs want an API, JavaScript customization, and full HTML/CSS editing suites. I think a two-type dichotomy isn’t descriptive enough, though. We need a third “semi-technical” user in the middle.

The spectrum of users could look something like this — we analogize these to an Microsoft Excel user equivalent (parenthesized):

Novice — anything that looks like code is totally opaque to novices. They’re scared off by it and afraid to change anything for fear of breaking something (Can enter data in Excel, and maybe do some sorting, filtering, or data manipulation)
Tinkerer — can parse through code examples and pre-existing scripts to roughly understand, uses trial and error and small adjustments to modify or piece together snippets for their own use case; often also can work with data and data tools like database applications and SQL (Can use formulas, pivot tables, lookups, and more with Excel, comfortable slicing and dicing data)
Developer — fluent in programming languages; excited about the prospect of writing their own code from scratch, just wants to be pointed to the API docs (Can write VBScripts and macros in Excel, but mostly wants to escape its confines to build their own software)

Of course empowering the Novices is one of the primary goals with low-code approaches, as they’re the least prepared to put together their own solutions. They need turn-key software.

And we can help Developers with low-code, too. If we can bootstrap common patterns and functionality through pre-existing building blocks, they can avoid repetitive work. Much of tool-building involves rebuilding 50-75% of the same parts you built for the last job, so low-code approaches can speed these folks up.

But the largest gap is that middle bunch of Tinkerers. Not only do they stand to gain the most from low-code tools. From my observations, that group is also the fastest-growing category. Every day as more tech-native people enter the workforce, or are compelled to dive into technical tools, people are graduating from Novice to Tinkerer status, realizing that many modern tools are resilient to experimentation and forgiving of user error. The tight feedback loops you can get from low-code affordances provide a cushion to try things, to tweak, modify, and customize gradually until you zero in on something useful. In many cases what a user decides is a “complete” solution is variable — there’s latitude to work with and not an extremely rigid set of hard requirements to be met. By providing building blocks, examples, and snippets, Tinkerers can home in on a solution that works for them.

Those same low-code tactics in user experience also give Novices and Tinkerers the prototyping scaffolds to build partial that can be further refined by a Developer. Sometimes the prototyping stage is plenty to get the job done, but even for more complex endeavors can greatly reduce cost.

✦

Shipping the Right Product

August 14, 2019 • #

This is one from the archives, originally written for the Fulcrum blog back in early 2017. I thought I’d resurface it here since I’ve been thinking more about continual evolution of our product process. I liked it back when I wrote it; still very relevant and true. It’s good to look back in time to get a sense for my thought process from a couple years ago.

In the software business, a lot of attention gets paid to “shipping” as a badge of honor if you want to be considered an innovator. Like any guiding philosophy, it’s best used as a general rule than as the primary yardstick by which you measure every individual decision. Agile, scrum, TDD, BDD — they’re all excellent practices to keep teams focused on results. After all, the longer you’re polishing your work and not putting it in the hands of users, the less you know about how they’ll be using it once you ship it!

These systems followed as gospel (particularly with larger projects or products) can lead to attention on the how rather than the what — thinking about the process as shipping “lines of code” or what text editor you’re using rather than useful results for users. Loops of user feedback are essential to building the right solution for the problem you’re addressing with your product.

Thinking more deeply about aligning the desires to both ship _something_ rapidly while ensuring it aligns with product goals, it brings to mind a few questions to reflect on:

What are you shipping?
Is what you’re shipping actually useful to your user?
How does the structure of your team impact your resulting product?

How can a team iterate and ship fast, while also delivering the product they’re promising to customers, that solves the expressed problem?

Defining product goals

In order to maintain a high tempo of iteration without simply measuring numbers of commits or how many times you push to production each day, the goals need to be oriented around the end result, not the means used to get there. Start by defining what success looks like in terms of the problem to be solved. Harvard Business School professor Clayton Christensen developed the jobs-to-be-done framework to help businesses break down the core linkages between a user and why they use a product or service¹. Looking at your product or project through the lens of the “jobs” it does for the consumer helps clarify problems you should be focused on solving.

Most of us that create products have an idea of what we’re trying to achieve, but do we really look at a new feature, new project, or technique and truly tie it back to a specific job a user is expecting to get done? I find it helpful to frequently zoom out from the ground level and take a wider view of all the distinct problems we’re trying to solve for customers. The JTBD concept is helpful to get things like technical architecture out of your way and make sure what’s being built is solving the big problems we set out to solve. All the roadmaps, Gantt charts, and project schedules in the world won’t guarantee that your end result solves a problem². Your product could become an immaculately built ship that’s sailing in the wrong direction. For more insight into the jobs-to-be-done theory, check out This is Product Management’s excellent interview with its co-creator, Karen Dillon.

Understanding users

On a similar thread as jobs-to-be-done, having a deep understanding of what the user is trying to achieve is essential in defining what to build.

This quote from the article gets to the heart of why it matters to understand with empathy what a user is trying to accomplish, it’s not always about our engineering-minded technical features or bells and whistles:

Jobs are never simply about function — they have powerful social and emotional dimensions.

The only way to unroll what’s driving a user is to have conversations and ask questions. Figure out the relationships between what the problem is and what they think the solution will be. Internally we talk a lot about this as “understanding pain”. People “hire” a product, tool, or person to reduce some sort of pain. Deep questioning to get to the root causes of pain is essential. Often times people want to self-prescribe their solution, which may not be ideal. Just look how often a patient browses WebMD, then goes to the doctor with a preconceived diagnosis, without letting the expert do their job.

On the flip side, product creators need to enter these conversations with an open mind, and avoid creating a solution looking for a problem. Doctors shouldn’t consult patients and make assumptions about the underlying causes of a patient’s symptoms! They’d be in for some serious legal trouble.

Organize the team to reflect goals

One of my favorite ideas in product development comes from Steven Sinofsky, former Microsoft product chief of Office and Windows:

“Don’t ship the org chart.”

The salient point being that companies have a tendency to create products that align with areas of responsibility within the company³. However, the user doesn’t care at all about the dividing lines within your company, only the resulting solutions you deliver.

A corollary to this idea is that over time companies naturally begin to look like their customers. It’s clearly evident in the federal contracting space: federal agencies are big, slow, and bureaucratic, and large government contracting companies start to reflect these qualities in their own products, services, and org structures.

With our product, we see three primary points to make sure our product fits the set of problems we’re solving for customers:

For some, a toolbox — For small teams with focused problems, Fulcrum should be seamless to set up, purchase, and self-manage. Users should begin relieving their pains immediately.
For others, a total solution — For large enterprises with diverse use cases and many stakeholders, Fulcrum can be set up as a total turnkey solution for the customer’s management team to administer. Our team of in-house experts consults with the customer for training and on-boarding, and the customer ends up with a full solution and the toolbox.
Integrations as the “glue” — Customers large and small have systems of record and reporting requirements with which Fulcrum needs to integrate. Sometimes this is simple, sometimes very complex. But always the final outcome is a unique capability that can’t be had another way without building their own software from scratch.

Though we’re still a small team, we’ve tried to build up the functional areas around these objectives. As we advance the product and grow the team, it’s important to keep this in mind so that we’re still able to match our solution to customer problems.

For more on this topic, Sinofsky’s post on “Functional vs. Unit Organizations” analyzes the pros, cons, and trade offs of different org structures and the impacts on product. A great read.

Continued reflection, onward and upward 📈

In order to stay ahead of the curve and Always Be Shipping (the Right Product), it’s important to measure user results, constantly and honestly. The assumption should be that any feature could and should be improved, if we know enough from empirical evidence how we can make those improvements. With this sort of continuous reflection on the process, hopefully we’ll keep shipping the Right Product to our users.

Christensen is most well known for his work on disruption theory. ↩
Not to discount the value of team planning. It’s a crucial component of efficiency. My point is the clean Gantt chart on its own isn’t solving a customer problem! ↩
Of course this problem is only minor in small companies. It’s of much greater concern to the Amazons and Microsofts of the world. ↩

✦

Browse the full archive →

✦