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 . That’s right. No statement. Or, if writing a user story, writing one that intentionally avoids specifying 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.

Remember when twitter had stars?

The beauty of starring (or “favoriting?”) tweets was precisely what probably bugged some people about it — the ambiguity of it all: ‘ 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:

(source: “Hearts on Twitter”)

But, back to the favoriting/starring feature. 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 ; 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 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 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:

The differences between designing for ‘paths’ vs ‘sandboxes’

Features created from “sandbox” mindset, thinking about possibilities rather than specific use cases, are often in nature.

Here’s a lightweight example: . 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:

Flagging topics in Slack 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:

Emojis for voting on categories!

Point being: Whatever the 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 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 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 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 underspecify user stories (yes, yes you should), but rather 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’ is the 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 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 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 specifying.

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 solve a clear and pressing problem.

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:

The distinction between Generative and Underspecified Features may be overthinking things, but…whatever.

Generative features are those that you believe will 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.

Who could have predicted this!

Generative features tap into our playfulness, and curiosity. They suggest rather than .

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!

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 for these creative use cases, but doesn’t encourage them.

In contrast, Notion — the —was built from the ground up to be a generative . It clearly fits in the 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 .

But, none of these are quite the generative use case I’m imagining. No, I am thinking about more of an enabling , with an unspecified use case.

At this point in this post, I was going to cite but… honestly… I struggled to come up with a single, great example of a generative feature. Generative , sure. Generative , harder to find. It’s as if, when it comes to business software, we have:

  • generative
  • features (that can be in creative ways)
  • APIs or documented ways for to do creative things
  • Services such as Zapier or IFTTT that allow 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 an organization all that often.

Okay. Now that we’re through that moment of radical honesty, I don’t feel like this of a great example of a generative feature in any way invalidates the idea I’m suggesting. And what this idea I’m building up to?👇

🥁

Sometimes, the approach that is can be detrimental. Sometimes, you just need to ship a feature because you have a hunch (or a ) 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:

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

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 more ways to use a pencil.

Did I mention that your responses are being ‘graded’ on a 1–3 scale for creativity? . 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 of pencils
  • use a pencil as an arrow

As an object, we can imagine 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:

  1. Web software rarely us to use a thing in any way beyond the intended use. Boo.
  2. We rarely 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 prioritize the opposite, features that allow for possibilities.

Let’s not forget to have—and leave room for—play!😜

Whaaa…?

Speaker, educator, and design leader. On a mission to make learning the hard stuff fun, by creating ‘things to think with’ and ‘spaces’ for generative play.