No specs. No prototypes. Yes, code.
We don't write any product specs. We rarely do prototypes. But we're fast. We face the reality much sooner than others. So we can iterate faster.
At Hyperinbox, we never write product specs. We rarely do prototypes. For the most part, we discuss design over Zoom, and we draw something up on a Miro board, and then go straight into code.
Unorthodox? Maybe. Fast? Hell yes. It's freakishly fast. We built our first fully functioning product in less than 10 weeks.
Here's our rationale: why spend your valuable resource creating imaginary reality when you could go straight into building the real thing?
Specs are an illusion of agreement.
Here's what we mean by "specs are an illusion of agreement." Product specs are illusions and vanity displays of reality. No matter how well you write your product specs, what you ship will always be different in the end. So why chase the illusion in the first place?
Prototyping takes a tremendous amount of effort.
This goes the same with prototypes. While prototypes do have some benefits, for example, you can kindle an exciting inspiration to your customers about your "end game." But prototypes suck up so much time and energy to build a high fidelity prototype. At some point, you'll start to wonder, "I might as well code this." If you're building a prototype to use it as a "visualization" of what the software might be, think about the amount of time and energy you're pouring into building fake stuff when you could be building the real thing.
Documentation is important, yes. But not in software.
Documentation is important, yes. But not in software. In software, it only creates a sense of agreement, not the agreement. To build a true alignment amongst your team and bring everyone one the same page, you need to get real. Ship real stuff. Doesn't matter if they aren't sophisticated. It's actually better if they aren't because you'll then have a chance to spot edge cases early on to accelerate your iterations.
The existential problem with documentation is that you need to be updating them as you progress. Who's gonna update your 10-page PRD, and who's gonna go back to Framer to reconfigure your high-fidelity prototype every time you make a change to your code?
Less documentation, the better. This way, you can face reality faster. It's scary to face reality, but we all need to embrace it to get to where we want to be.
So, instead of spending days on writing product requirement documents (PRDs), just go build what you have in mind.
Basecamp influenced many of our ways of working. Having no specs and prototypes is one of them. We recently read a post by Dan Kim over at Basecamp on this topic. It served as a good reminder and inspiration for us to share our thoughts on this.
If you are remote, and want a universal inbox that integrates with all of your daily apps (Figma, Slack, Github, Jira, Asana, etc.), join the Hyperinbox waitlist. And follow us on Twitter, @hyperinboxapp!
