On Generative Features
Or, the Value of ‘Underspecifying’ a Product Feature
A potentially contentious point I bring up in my “Paths to Sandboxes” talk is the value of “underspecifying” a feature. Essentially, I suggest we might design, build, and ship a feature with no specified use case. That’s right. No “As a [user]… I want to… so that…” statement. Or, if writing a user story, writing one that intentionally avoids specifying why someone wants to take that action (the “so that” part of that statement).
Huh?
Example, please?
The—now dated—example I bring up is Twitter, waaay back in the days when “starred” tweets were a thing.
The beauty of starring (or “favoriting?”) tweets was precisely what probably bugged some people about it — the ambiguity of it all: ‘What does starring a tweet mean? Tell me—please!’ At one point, I recall someone identifying at least 11 different reasons to star something. Top of mind, I can recall…
- to signal agreement, gratitude, laughter, support
- to vote on things
- to bookmark or save something for reference later
- to attract new followers
- as a trigger into external services like IFTTT or Zapier
- a kind of read receipt to acknowledge replies, or to say thanks
- for brand/testimonial curation
- to keep track of favorite posts
- and so on!
Indeed, this ambiguity and confusion was probably a reason for the update in 2015. According to (then) product manager Akarshan Kumar:
We want to make Twitter easier and more rewarding to use, and we know that at times the star could be confusing, especially to newcomers…
(source: “Hearts on Twitter”)
But, back to the favoriting/starring feature. Why might it be preferable to stick with the vague—potentially confusing—version of a feature?
Why would you want to underspecify a feature?
The context for my ‘sandboxes’ talk is about creating platforms for engagement and learning; it’s about designing playful spaces where it’s OK to leave room for unexpected use cases. I hold up examples like Twitter, Pinterest, Minecraft, Trello, and others as platforms that do (or did) exactly this—allow for the unexpected use cases. Were I to give an updated version of this talk, I might reference similar ‘horizontal’ software tools such as MURAL, Roam, AirTable, or Notion. Fundamentally, I’m talking about generative spaces, where people are free to create their own—often unpredictable — ways of using a thing. (Litmus test: If someone asks ‘What’s this for?’ or needs templates and examples to spur on ideas, then it’s probably the kind of generative platform—or feature—I’m talking about!).
There’s more to it, but here’s the one-slide summary of that talk:
Features created from “sandbox” mindset, thinking about possibilities rather than specific use cases, are often generative in nature.
Here’s a lightweight example: Emojis. While ostensibly about expressing emotions (most often in messaging app), they’ve been used in all sorts of creative ways. Within my team, we recently started using the 📌 (pushpin) emoji to flag non-urgent topics for future discussion:
A simple Slack search query 📌 from:@Erik from:@Stephen P. Anderson (that we could probably route into another Slack channel, MURAL canvas, or Google Doc via Zapier), now brings back the topics for discussion that we’ve been sitting on…
Or, I’m sure you’ve seen this one: Using emoji’s for voting/polling:
Point being: Whatever the intended use case, people will (try to) find their own ways to use and utilize a thing. This is OK. I’d argue this is something to be encouraged. Heck, it’s human nature. For businesses, underspecified features can be a kind of ‘let’s wait and see how people use it’ experiment. This has certainly been the strategy for companies that build public facing APIs. But even in the absence of an API, if the motivation is strong enough, people will often find ways to ‘hack’ your tool to suit their needs. The emergence of hashtags in the early days of twitter (long before hashtags were an official feature) would be a prime example of allowing for and then learning from these unspecified use cases.
In the context of my ‘Paths to Sandboxes’ talk (which weaves a compelling narrative), I’ve yet to hear anyone disagree with what I’m proposing. However, I’ve also yet to see a product (or project) manager who seems comfortable with what I’m proposing, which is to build and release a feature with no specified use case. Here’s the issue: To design a sandbox experience is all about giving up control. It’s about not knowing what to measure. For designers, it’s about not knowing the experience to optimize for! No precise customer journeys or user flows to design against.
But, the question isn’t should we underspecify user stories (yes, yes you should), but rather when should we underspecify specifications?
First, the other extreme: Overspecifying
A lesson I’ve learned now, on multiple occasions, is the danger of over-optimizing for a particular set of use cases. This is overspecifying.
‘Overspecifying’ is the ‘let’s build ‘X’ specifically for ‘Y’ role’ mindset, more likely to come from sales and marketing. For designers, it’s the allure of designing an experience perfectly tuned to the needs and wants of a particular user base. For product managers, it’s about prioritizing what that user wants. Unless you’re careful or lucky, you’ll end up building things in such a way that it doesn’t scale to a broader set of users (the cop out, of course, is to build a bunch of toggles, under the guise of making things configurable). As much as possible, we should always look at as many possible use cases, then abstract. What less specified feature, or feature set, could be offered that might satisfy several use cases at once?
One of the things I try to practice in my work is precisely this kind of abstraction. It’s easy to listen to a request for a toggle here or this feature there, and react. But, what’s really being asked for? And could we design, build, and ship this in such a way that we solve for several job stories at once?(And allow for others?)
To be fair, the really good and great PMs I’ve worked with do not work in this kind of reactive manner. They do look for the pattern worth investing in. They don’t copy the implementation pattern set by a competitor.
So that’s overspecifying.
Generative Features (vs Specified Use Cases)
I digress. Let’s return to the point of this post… I also have not encountered very many teams who are comfortable in the opposite scenario: Investing in a feature that doesn’t solve a clear and pressing problem.
Me: We should build this thing
PM: Why?
Me: I think there’s a lot of cool things it might allow people to do.
PM: Ok. But, what problem does this solve for the user?
Which leads me to the extreme end of underspecifying features: Generative features. If we were to line things out on a continuum, you might end up with something like this:
Generative features are those that you believe will enable amazing things, many of which can’t yet be imagined. Cue up images of redstone and switches in Minecraft. What was intended to allow players to build automatic doors, lights, and trap doors, ended up being used to build functional 16-bit computers.
How it started:
How it’s going:
Generative features tap into our playfulness, and curiosity. They suggest ‘what if’ rather than ‘how to’.
A recent, playful example of this might be Zoom backgrounds. While the majority of us use backgrounds for personal expression (I love joining people from the inside of the Rocinante or Tony Stark’s Malibu mansion), some clever soul figured out you could fake attendance in a meeting by placing a looped video of yourself as the wallpaper. At MURAL, we rather enjoy our virtual gatherings, so we ‘hacked’ Zoom backgrounds in quite a different—and collective—way. For our 2021 company retreat, MURAListas were asked to add one of several ‘maze’ backgrounds to our zoom sessions, which added to the imagined experience of being “lost in the maze” together!
Speaking of Zoom, I’ve also seen facilitators ask participants to update their names—adding an ‘A’ ‘B’ or ‘C’ in front of their names—to indicate which group they’d like to join. That might be another unintended but useful use of the name editing feature. That said, Zoom is a fairly locked down tool, and doesn’t allow for much of what I’m describing here (or else I need to be more creative!).
But, these are all ‘hacks’ — the system allows for these creative use cases, but doesn’t encourage them.
In contrast, Notion — the “all-in-one workspace for your notes, tasks, wikis, and databases”—was built from the ground up to be a generative tool. It clearly fits in the “what’s this for?” box, with a rich, vibrant community ready to show off all manner of use cases. But even with all of the built in flexibility, users have been pushing the boundaries of what is possible. In late 2019, some folks recognized that Notion might work to setup a simple web page. Instructions followed and soon people were launching web sites with Notion (Notion has since incorporated and smoothed out this particular use case).
But, none of these are quite the generative use case I’m imagining. No, I am thinking about more of an enabling feature, with an unspecified use case.
At this point in this post, I was going to cite ‘a playful example of this in business software is’ but… honestly… I struggled to come up with a single, great example of a generative feature. Generative platforms, sure. Generative features, harder to find. It’s as if, when it comes to business software, we have:
- generative tools
- underspecified features (that can be hacked in creative ways)
- APIs or documented ways for those with knowledge to do creative things
- Services such as Zapier or IFTTT that allow anyone to work with APIs
- programming the web, itself
So, confession time, I struggled to come up with a strong example of a feature that is generative like I’m describing here… 😱 (Do feel free to suggest an example in the comments!)
That said, I did notice that third party groups (often individuals) are more likely to build the kind of generative features like I’m describing here, often for a preferred product/service; see this tool that shows a progress bar on your Twitter profile picture or this interface that allows anyone to quickly build a D3.js-based data visualization. But, I didn’t sense that these kinds of generative features coming from within an organization all that often.
Okay. Now that we’re through that moment of radical honesty, I don’t feel like this lack of a great example of a generative feature in any way invalidates the idea I’m suggesting. And what is this idea I’m building up to?👇
🥁
Sometimes, the “what problem are we solving for our users” approach that is de rigueur can be detrimental. Sometimes, you just need to ship a feature because you have a hunch (or a hypothesis) that it’ll unlock some really mind-blowing things that we—as authors / designers / creators / developers / whatever—can’t yet imagine. Wallpapers. Adding support for gifs. Progress bars on profile pics.
I could go on.
If you find any of this intriguing, Kars Alfrink gave a brilliant talk on this topic in 2008; he makes a far more compelling and articulate argument than anything I’ve written here. His summary:
1.
The role of design in rich forms of play, such as skateboarding, is facilitatory. Designers provide tools for people to play with.2.
It is hard to predict what people will do exactly with your tools. This is OK. In fact it is best to leave room for unexpected uses.3.
Underspecified, playful tools can be used for learning. People can use them to explore complex concepts on their own terms.
Let’s end things by putting a ‘fine point’ on all of this…
On the many uses of a pencil
There’s a group creativity exercise some of us may have practiced. It’s quite simple. You take an ordinary object, say… a pencil, and you imagine as many different ways we might use a pencil, (usually within5 minutes). For example…
- you can draw with a pencil
Booooooorrrring.
Of course this is not very creative and once it’s been stated that leaves four minutes and fifty seven seconds to fill up the time with dozens more ways to use a pencil.
Did I mention that your responses are being ‘graded’ on a 1–3 scale for creativity? Quantity [‘x’] multiplied by the creativity (1–3) of each response. With the boring and expected use of a pencil out of the way, we can start being creative…
- you can chew on it
- use it like a rolling pin
- fancy a drum session, anyone?
- roll your toothpaste tube
- use it to make a hair bun
- emergency chopsticks?
- make a totem pole for ants
- break it into pieces — make it a raft for the people who live in the cupboards
- get all John Wick with it
- make nunchucks by creating two bundles of pencils
- use a pencil as an arrow
- and so on…
As an object, we can imagine many ways a pencil (or pencils) could be used, beyond the intended use.
And here is the point I’m making: It’s not that there doesn’t need to be a specified use case (pencils = writing). But, let’s substitute the real world analog pencil with that feature you just released. Thinking of a feature through the analogy of the pencil lets us see two things:
- Web software rarely allows us to use a thing in any way beyond the intended use. Boo.
- We rarely design digital tools to be used in generative ways. But, we could. And that’s the point I want to make.
“Don’t see yourself as a maker of media, but as a creator of tools. The use of which you can never fully predict. There’s two ways to handle this uncertainty: one — try to eliminate any chance of people messing with it, or two — embrace this uncertainty, and leave open opportunities for new play forms.”
— Kars Alfrinck, on his stance as a designer.
My proposition is really simple: Allow for people to ‘hack’ your tool in a way that surprises and delights. Build features in such a way that they could be used in alternative ways. Don’t get hung up on everything you prioritize needing to solve a problem — it’s ok to also prioritize the opposite, features that allow for unexpected possibilities.
Let’s not forget to have—and leave room for—play!😜
