Stop building features “for exposure”
Without a coherent hypothesis for both user outcomes & business impact, a product team’s outputs are waste rather than value
When thinking about product development, I perpetually return to two powerful ideas:
- Design works through abstracting and adapting systems (including from one domain to another)
- A product is a system for delivering value, which means that a design practice is a kind of product that can be designed
Combined, these ideas form a thesis: through studying other systems of value delivery, we can design not only products that are more valuable to our users, but also a practice that is more valuable to our organizations.
And one of the most important aspects of a value-generating system is how that system transforms resources and effort into waste.
Getting nothing for something
If you are asking me to do work for exposure, you have to explain to me why it’s not the kind of exposure people die of. — KJ Charles
Value is a matter of perspective; when we say “we are creating value” the next question should always be “for whom?”
No domain better illustrates this principle than writing. In pure economic terms, the value of a writer’s writing is not the text itself, but in the ability to sell it to someone (such as a publisher who, in turn, derives value from putting the writing next to some ads). In theory, both the buyer and the seller of the writing gain value from the exchange.
However, many writers are offered a much more dubious exchange: for exposure. In other words: if you give me free stuff, others will see what a great job you’ve done.
Writers who follow up to understand exactly what kind of bump in commissions or book sales others have actually seen as a result of this exposure are usually met with abstract promises and few if any figures. They are just being asked to work for free, but with extra steps.
Writers who end up working “for exposure” are still creating value — for their “customer.” But for themselves, this work has no value.
Time & resources spent on outputs without value have another name: waste.
Which brings us back to software.
One man’s waste is another man’s velocity
[Many designers] think that ‘user centricity’ is self-evidently desirable. As a result, they can’t make convincing business arguments for their role. — Jorge Arango
Unlike freelance writers, product teams typically work for a salary. And yet, they do a tremendous amount of work “for exposure.” It’s just that the pitch looks slightly different: instead of “write me this article so that people can read it” we can observe “add this feature to the app so that users can use it” across every product backlog in the nation.
From the perspective of the organization, it’s exactly the same situation as working for exposure, and just about as effective. The resources expended towards these features are converted directly into waste at 100% efficiency.
Who will see it? What will the impact of them seeing it be? How have previous features performed? How will this work actually fit into the business strategy?
Unless you can answer all of these questions, you’re building features for exposure.
Build-measure-learn optimizes for waste
People get obsessed with “change” as a substitution for “leadership” so they interpret “little change” as evidence that leadership is missing. — Joshua Foust
One of the most common arguments used when building features for exposure is “we can’t answer those questions until we ship and see.”
Sometimes, this will be true. For those true zero-to-one products, with nothing at all in production, there’s no replacement for real data from real users (although, once again, you really should be studying analogous domains).
But somehow the same argument ends up dragging past that first release: we still can’t know, we have to ship more. The absence of measurable impact is interpreted not as a lack of value, but as a lack of outputs.
And until the system is interrupted, the cycle of waste continues.
Just like the author must ask how “exposure” will convert into book sales, we must ask how shipping will actually turn into seeing. What will make this release different from every previous release, so that we may at last begin to measure and learn?
Or, when the feature is done, will we begin working on the next assumption-informed feature in the roadmap, until someone realizes that all of this velocity amounts to waste and starts pointing fingers?
