Shakti Mb, of Santori Labs, is a software designer and filmmaker.
getty
After a decade working in software design, I feel zero-to-one design work is categorically a different challenge. There's no prior product to react to, no crisp user problem, no competitor to emulate, and yet there are real-life constraints to oblige. What does exist is a founding team, a thesis and an emerging force (technological, cultural, infrastructural) that suddenly makes an opportunity possible. Your job is to figure out what the product even is.
But zero-to-one work itself isn't one singular thing, and understanding that difference is valuable.
The first type starts with something that already exists, i.e., friction, frustration or a job that people are struggling to get done. The user can usually articulate it, or at least you can observe it. Uber is often framed this way: Hailing a cab was painful, so here's a better version. The problem exists before the product, and your job is to close the gap. The success criteria can be stated in advance.
The technology push paradigm is categorically different: A new capability (technological, infrastructural, cultural) is looking for a problem. The user, crucially, does not yet know they have a problem. You're not closing a gap here as much as you're operating on a thesis.
The cardinal sin is conflating the two because the confusion can slow you down and generate false signals. You can validate yourself into a dead end. What makes this so confusing is that, unfortunately, the standard toolkit of product design is all geared toward market pull.
In my view, there are a few reasons for this. First, organizations are structurally uncomfortable with not knowing. Roadmaps, OKRs, sprint cycles and stakeholder updates all create pressure to have an answer before you even know what you’re building.
Second, the double diamond framework taught in design programs and used in most product teams and its entire logic (discover, define, develop, deliver) presupposes that there is a problem to be discovered and defined before you develop toward it.
"Jobs to Be Done" has the same limitation; it still instructs you to identify a job that people are already trying to get done. When the job itself is being created by a technological or cultural shift, JTBD gives you nothing to grab onto.
These aren't bad tools, but they're the wrong tools, applied to the wrong problem. When a new technology makes a new opportunity available, you’re operating on a thesis. And all these tools become the wrong tools.
Six years ago, I began studying filmmaking alongside my software design career (night classes, online courses, volunteering for friends, fellowships and residencies). Soon, I would learn that the documentary field would provide me with the vocabulary for a kind of process that zero-to-one design requires.
Consider what the English word "edit" implies: You start with something and remove what doesn't belong. The meaning already exists; you're cleaning it up. Problem-solving design has this logic underneath it. The problem preexists you, and your job is to find it and refine it into a solution.
English and Spanish have different words for what is colloquially regarded as this editing process. "Montaje" (the Spanish word for editing) implies a more constructivist process: Its root is assembly, the bringing-together of fragments into a whole that did not previously exist. Meaning or story doesn't preexist the edit. Rather, it emerges from it. In product work, those fragments are the team’s instinct and conviction, user reactions, technical constraints, half-formed instincts and other things you can't yet name.
At Tempo, an AI thinking tool I designed with my team from the ground up, we spent months on UI-first explorations like node-based interfaces, canvas layouts and multistep flows. We kept returning to visual explorations that represented the act of thinking: nonlinear, spatial, connective. We arrived, finally, at a conversational chat interface, the most familiar pattern in LLM software, hiding in plain sight.
That answer couldn't have existed without exhausting every other pattern first. What we were constructing, through all of it, was more than just UI; it was an understanding of what the problem we were really solving was.
Peter Thiel wrote that the act of creation is singular and that the result is something fresh and strange. What he's describing, I think, is montaje.
Editing presupposes that the meaning is already there, waiting to be uncovered and that your job is essentially archaeological: a process of shaping and reshaping until the right form is visible. What montaje points at is the experience of constructing something whose final form could not have been specified in advance, because it arrives through the work itself.
You could call all of this iteration, but iteration implies a feedback loop tightening around a “correct” answer. But montaje emphasizes a process where meaning doesn't preexist the iteration. At Tempo, we didn't arrive at a conversational user experience despite spending months on node-based canvases and spatial interfaces; rather, we arrived at it because of doing that. Those explorations were the assembly. Without them, the answer would have been a guess.
In documentary and in zero-to-one product work, you are not navigating in the dark entirely. The North Star holds: the high-level intent, the emotion and the mission, most of which remain largely fixed. What is radically unknown is the path, which can only be found through assembly, iteration, exposure, feedback and reassembly.
You do not arrive at something genuinely new by optimizing toward a known answer. You arrive by remaining faithful to a method that tolerates not knowing, for long enough that the thing can reveal itself through its own assembly.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。