Workflows and worldviews // Deciding where your product ends // Idea traps
I once heard Des Traynor, founder of Intercom, say something like (paraphrased from an old memory):
Your product should (1) take responsibility for as little of the workflow as possible and (2) integrate generously with all the tools on either side.
People like to work their way, so the more steps of a workflow you bake rigidly into the product, the more chance of including a deal-breaker.
I’ve abandoned so many almost-incredible community management tools for the simple reason that they kept trying to claim more and more of the workflow (like some sort of digital manifest destiny) until they ended up including a step that I didn’t want and couldn’t avoid, forcing me to abandon altogether.
Or: everybody’s productivity stack includes the same mundane trio of email, calendar, and a todo list. And yet, not a single attempt to integrate those three pieces has succeeded in going mainstream.
You’ve probably had an argument with a partner/housemate that wasn’t only about *who* does the dishes but was about *how* that person does the dishes. People like tailor-making their own workflows. your “efficiency” is my “wtf” (and vice versa). While Zapier and Notion are building empires by embracing and enabling this behavior, the startup graveyard continues to claim the husks of projects that deny it.
Just as student-founders tend to fall for sitcom startup ideas, there’s a tendency for nerdy, intellectual founders (myself included) to fall for “too much workflow” ideas. It’s an idea-selection anti-pattern. I’m not entirely sure why these ideas seem so compelling… Perhaps we like to believe that a messy process (and by extension, a messy world) can be “fixed” by codifying the thing into some arbitrary platonic ideal of step-by-step SaaS[1].
But messy reality will break free of these arbitrary containers, and you end up with waiters drawing on the screen.
—
It’s hard to imagine a tougher headwind than attempting to change customers’ workflows or worldviews (i.e., how they do things).
I remember talking to an African entrepreneur who had designed an incredible DIY harvester, only to fail because local farmers refused to plant their crops in rows. Or there’s an anecdote in The Idealist📕 (a book about the doomed Millennium Villages Project) describing a drought-stricken region that desperately wanted help, only to rebel at the idea of drying wild grass as hay to feed their animals, because that’s not how they did things.
From a custdev perspective, this type of idea is especially tricky since customers are highly passionate about describing the problem and its implications (“we’re gonna fuckin’ starve!”), which gives a strong positive signal. But then, once you’ve built the thing, it will be rejected over some seemingly innocuous triviality. (i.e., Strongly positive signal about the problem, and strongly false positive signal about the solution.)
—
Two naive solutions are (1) educating the customers and (2) adding flexibility to the workflows within the product.
Education works in theory, but it’s slow. In Four Steps to the Epiphany📕 (the original custdev bible, although now outdated), Blank suggests that if you’ll need to educate your customers, you ought to add five years to your timelines for getting started. So that’s… not super viable.
(Plus, sometimes “education” is code for saying, “We don’t want to spend the time to understand our customers as they actually are, so we’re going to try to change them into what we’d like them to be.”)
Adding flexibility for multiple workflows also works (in theory), but at the cost of massively increased development (lots more features) and support (lots more fiddly edge cases). So this is usually something that companies grow toward (like today’s Salesforce, Hubspot, or Stripe) and not something that they begin with.
Two better solutions, I think, are (1) empathy and (2) simplicity.
On empathy: the lucky iron fish (i.e., a hunk of iron dropped into cooking pots to resolve iron-deficiency) wasn’t originally fish-shaped. There’s no reason it needs to be. But although Cambodian villagers steadfastly refused to put a random hunk of metal into their cooking pots, they were delighted to do so once it was fish-shaped, because fish are lucky and belong in a cooking pot.
Instead of expecting people to change for your product, maybe you can find a way to change your product to be a better fit for them. That’s the empathy bit.
Simplicity comes back to Des’ original advice:
The most important thing a product manager does is decide where their product stops and someone else’s product takes over.
—Des Traynor, Where to draw the line
Focus on one important slice of the workflow (which could involve a couple key steps), avoid overreaching in either direction, do a good job with your bit, and integrate with the existing tools on either side.
Folks can then adopt your product as a crucial piece within their existing workflow. And once you’ve got that stable toehold, you can decide how you’d like to grow from there.
—
[1] One weirdly-specific (but also weirdly common) version of this workflow blunder is when folks set out to codify the process from a nonfiction book into SaaS. But the whole strength of nonfiction, as a medium, is that people can borrow piecemeal from a book, adding as much or as little as they like to their existing process, and personalizing/customizing it as they do. You can’t do that with SaaS, which is part of why I’ve never wanted to make any sort of “mom test: the app.”
Comments (14)
The issue with overreach is you dont know you overreach for sure until you have actually overreached
“Your product should (1) take responsibility for as little of the workflow as possible and (2) integrate generously with all the tools on either side.”
Read it once, didn't get it...
Read your article through and then read it again > eureka!
Boundaries and EmpathyWhere to fit in, where to draw the boundaries between your product and the other tools out there, is essential. You helped clarify that! This reminds me of a quote in Willpower(Baumeister, Roy), on bright lines:
“ “He needs the help of “bright lines,” a term that Ainslie borrows from lawyers. These are clear, simple, unambiguous rules. You can’t help but notice when you cross a bright line. If you promise yourself to drink or smoke “moderately,” that’s not a bright line. It’s a fuzzy boundary with no obvious point at which you go from moderation to excess””
I included the drink/smoke on purpose, I think it's like an addiction to adding more stuff/process/planning than you can actually deliver, and more importantly, more than the customer really wants (same as feature bloat).
My issues:There are loads of resources in language learning space, but they're almost all just in Icelandic(so you need to learn Icelandic, to learn Icelandic...).
There are courses out there, material that has been made, but is poorly executed. But it's been sitting right in front of me:
• Can I take a poorly executed course and make it 10x better?
• Yes.
• Can I make rough drafts, iterating on ideas as I go along, chaotically at first, not giving a damn about organising?
• wait, you can do that? lol
What I've tried doing is thinking of a solution that solves 300% of the actually pain point, with 10.000% work needed to achieve it! ie. impossible.
“Instead of expecting people to change for your product, maybe you can find a way to change your product to be a better fit for them. That’s the empathy bit.”
well said!
Ideals“Just as student-founders tend to fall for sitcom startup ideas, there’s a tendency for nerdy, intellectual founders (myself included) to fall for “too much workflow” ideas. It’s an idea-selection anti-pattern. I'm not entirely sure why these ideas seem so compelling… Perhaps we like to believe that a messy process (and by extension, a messy world) can be “fixed” by codifying the thing into some arbitrary platonic ideal of step-by-step SaaS[1]. ”
So glad I'm not alone in trying to design amazing workflow before having anything to put into it...[126omQ0GgfVVmw.gif]
Perfectionism and idealism are great, but they need the harness of reality to say: "what's the(singular, uno, one, einn) worst pain that the customer is experiencing? Can you deliver them from that pain? what's possible now?"
Like PG says, "don't look for startup ideas." ie. don't create a castle in midair.
“But messy reality will break free of these arbitrary containers, and you end up with waiters drawing on the screen.”
LOL! Loved this article! Nb. this was in Norrköping though, so, that does play some role in this.
Focus and overreaching“Focus on one important slice of the workflow (which could involve a couple key steps), avoid overreaching in either direction, do a good job with your bit, and integrate with the existing tools on either side. ”
[3ohzdIuqJoo8QdKlnW.gif]
How can we keep checking that we haven't gone astray?
Take regular holidays and/or breaks?
Take a step back and see things from a macro perspective?
Addendum: Michael Siebel from YC talking about the process of building product. Starts at 19.45
“What I find interesting is that a lot of people think of building a product as a painting. As something that could be appreciated as a piece of art, as something - even if it's just appreciated by one person, special. That's not what you're making! Products are not paintings, they're not art. If users don't find the product useful then the product is by definition not useful; and they're a waste of your time to build. And a lot of people want to be artists. The startup world is very unforgiving to artists.”
Apropos being a nerdy workflow person (totally relate), isn't it just sometimes solving things that don't need solving, just turns into the depths of the midwit area of the spectrum!? ie. overthinking/overbuilding/overplanning enough to actually never release anything to the world 😆
YC's Dalton Caldwell and Michael Siebel had a very good video on this just recently.
I'd love to hear your thoughts Rob if anything is stirred up by this!
[aGzQOE5_460swp.webp]
For the question of " How can we keep checking that we haven't gone astray?" (which was also mirrored by ), I think I'd say something like:
1. For getting started, I'd start by using the heuristics from Des' article, especially the one about drawing the line if you're about to start doing stuff that's already handled by by several mature, entrenched tools.
(Example: for the OOC email helper, I'm intentionally avoiding any sort of editing/formatting/sending, since that would be asking people to "change their workflow" away from their current newsletter service, and am instead "drawing the line" by just ensuring that my outputs can be pasted cleanly into whatever email tool they already use.)
2. If you aren't sure about the above, it might be a sign that you're lacking in either understanding the customer (what they're alredy doing and why) and/or understanding the industry (standard tools, workflows, constraints, etc.).
3. Throughout development, look for signals that you've overstepped, which can be something like loads of opinionated customer support requests from people who all want different things from the same feature. That's a sign that you've stepped into a strongly opinionated/personalized piece of the workflow, and you might want to roll that one back and let people integrate with their comfort tools (alternatively: could take a strong stand on WHICH of those people you're going to serve, and then focus only on their preferred workflow).
(Example: with helpthisbook, we originally had some basic editing features to adjusting and "fixing" an imported manuscript. But that ended being extremely fiddly/opinionated and generated a ton of feature requests and complaints, so we ended up drawling the line earlier by removing *all* editing features and telling people that our tool is 100% for display and feedback, 0% for editing, and adding better documentation about how to get their desired layout via GDocs.)
Not 100% sure on the above though... It's my current understanding and best guess, but this is relatively new territory for me to be thinking about.
That Seibel/Caldwell video was excellent -- thanks for posting.
Re: workflows, I'm not totally sure on root cause, but I think it's some sort of naive belief that any low-tech workflow is inherently bad. E.g., thinking that anyone using post-it notes and spreadsheets will be so much more efficient with the right SaaS... But actually, sometimes postits are the right tool for the job.
So maybe sort of "tech elitism" combined with not understanding all the nuance that goes into the current process. (Postits and spreadsheets are infinitely customizable by the users to handle edge cases on the fly, in exactly the way that most SaaS apps aren't.)
I used to say quite often that most startups aren't competing with other startups: they're competing with some combination of telephones, email, and excel. That's probably applicable here. So there's a humility in leaving all that stuff alone and focusing on a small piece where you can add big value.
> they're competing with some combination of telephones, email, and excel.
In my revenue generating work, i can safely say i am competing against email and excel and inertia / status quo.
I will summarize as
B2C, you compete with chat or end up having a chat based system.
B2B, you compete with email + excel/word or end up having a system that looks like excel/word.
> How can we keep checking that we haven't gone astray?
My earlier comment is
1. we don't know for sure, we have overreached until we actually overreached. (See Rob's example about helpthisbook and editing taht reflects this)
I will add to that comment with a follow up
2. there's no proof that you need to avoid overreach at all costs.
Also see Rob's example about helpthisbook and editing. They overreach and they now pull back.
It's a reversible decision. See Jeff Bezos and Amazon talking about reversible decision.
3. 1 + 2 doesn't mean you do zero precaution about overreaching or not think about it at all or be totally reckless.
All i am saying is, yes, be aware of this. but don't let this paralyze you.
just try. if you overreach, pull back. Make some contingency plan (within reason) in case yuo overreach before you try.
overthinking about the fear of overreaching is also a form of overthinking, i feel
this was helpful though, even if, like you said, not 100%
So…
Drawing a line early
Pull back the line (it isn’t too late)
Unsure of the line? == Do you really understand your customer?
Look for signs along the way: are you meeting animals in the forest(opinionated customers)?
Perhaps running away is smart
Or
consider crafting a specific weapon(tool) to deal with the most common animal: wolf-imploder-3000! Be a smart red-riding-hood.
Help this book:
Rolling back a feature that is just creating a headache for you 👌 Very nice!
Will keep that in mind.
Np! Happy to hear it, some other video uses your Mom test book as an example of how to talk to customers. You prob knew though :p
Elitism/doubt of low tech solutions: yes… damn, I’m guilty on all counts
“So there's a humility in leaving all that stuff alone and focusing on a small piece where you can add big value.”
Mmmmm. Save this. Sometimes you say things like this, in your posts, in your books, that are a concise, to the point, and so so quotable.
Yes!, 🙌
“just try. if you overreach, pull back. Make some contingency plan (within reason) in case yuo overreach before you try.
overthinking about the fear of overreaching is also a form of overthinking, i feel”
I 100% agree; if you’ve done the pre-work and aren’t spreading yourself too thin, then some overreaching might bring some interesting results, or not 😂
This is a good explanation of why Hashicorp's early products were so successful. They gave the basic building blocks for a set of shared problems and it was up to the individual to combine those blocks into a solution.
Same with Stripe. They gave you an easy solution that worked for enough people but you could integrate their service with your site fairly easily.
Do you think there are situations where you want to force a specific type of workflow, even though the customers may push against it?
I've seen way too much of this in enterprise software where the people making the purchasing decision are far removed from daily users. In some instances, this was needed (e.g. security/compliance) and in others, it was not.
Forced workflows are usually done for the benefit of upper management: better data, etc. An example where this ends up being a big net positive is getting salespeople to shift to using a CRM instead of keeping everything in a rolodex. They hated it at first, but it was important enough to upper management that they were willing to force the issue, and then salespeople ended up a lot more effective (and getting bigger bonuses) as a result.
Whereas an example of it being a net negative is the data point that doctors now spend 60% of their workweek doing tedious form-based data entry for the sake of insurance companies and litigation protection, forced through an extremely badly designed workflow for dumb reasons.
In the CRM example, do you know of any approaches that would help reduce the backlash?
I'm more familiar with "agile transformation" or "cloud transformation" world. Those are multi-faceted problems with so many stakeholders and little buy-in across the board, that those initiatives almost always fail.
I'm wondering with something like introducing a CRM or similar changes, can you drive this kind of change bottom-up as an external vendor or is having "executive alignment" a must?