It feels nice to ideate and plan for a glamorous future. I did that on so many projects that never saw the light of the day or that failed after a few months. That can be interpreted as a kind of procrastination.
I want to share with you something that I learned while being a failed entrepreneur, reading startup stories, and working as a Product & Marketing Manager at a Y Combinator accelerated startup. Most beginnings are so humble and scrappy that you would not believe it. The first example that comes to mind is DoorDash ($16 billion valuations), they made their MVP in one afternoon by gathering restaurant menus from around the area where they lived, listing them into a landing page, and adding their own phone number for people to take orders. Then, the first person called to order Thai food, and that's how they got started. Receiving calls, getting orders from the restaurants, and delivering them themselves.
”We didn't have any drivers; we didn't have any algorithms; we didn't have a backend; we didn't spend six months building a fancy dispatch system – we didn't have any of that. We just launched because at the beginning it's all about testing the idea, trying to get this thing off the ground, and figuring out if this was something people even wanted. And it's okay to hack things together at the beginning.” — Stanley Tang, DoorDash co-founder.
DoorDash MVP screenshot from "Lecture 8: Doing Things That Don't Scale" by Y Combinator.
With this in mind, I started pushing against my perfectionism and obsession to build a full-on experience from the get-go. I always ask myself what is the absolute minimum amount of documentation and work that can help get an MVP into users hands? That’s when I started using what I call a “Short Product Requirement" and just get started on building a POCs in a matter of hours.
Short Product Requirement document structure:
- Main Persona(s)
- Main Problem
- Solution
- MVP feature list
- A north star metric/goal of this MVP
- Pencil design mocks and a basic UI flow
- A high-level linear to-do list
- Most blocking/challenging tasks first, and each done task unlocks the next one
- A few go to market and sales ideas
You can get a copy of the Short Product Requirement Document template on Google Drive.
Most of the time the to-do list involves making some POC code, creating a landing page, and directly reaching out to a few users to see if I get any traction and learn something along the way.
”Do Things That Don't Scale.” — Paul Graham, YC co-founder.
While working on my side project tagmate.io, I could've created a backend that generates the code and automatically adds each user’s domain to the allowlist, but I chose instead to just copy the scrappy widget code folder and allowlist the domains myself for each customer. I knew some startups like Hotjar or FullStory provided their users with similar experiences to what tagmate.io offers, but I did not know if they wanted to have this functionality as a third-party service, I did not know if they want to pay a subscription for that or if they prefer to develop it in house.
I could've just asked before building anything, right? I think asking people about something and showcasing something is not the same, people might say that they are interested, but they actually aren’t and vice versa. Having a product in your customer’s hand is a better user experience than nothing, and you will learn more from the former than the latter.
That reflects too on parts of my work as SlimWIki’s Product Owner (an OOZOU- owned product), where we try to apply the same principles by keeping documentation to the bare minimum, reducing the product scope to focus on our core value proposition.
We’re using an adapted version of Shape-Up by Basecamp for almost a year now, and sometimes it's not possible to shape up a fully detailed plan for programmers to start working on the upcoming development cycle. That's not always ideal, and having a software developer background myself, I understand the need for more details and precision. But as a Product Owner, I believe it makes more sense to have minimum viable documentation and keep answering questions along the way.
“With minimal planning, you move forward with the user. With extensive planning, the user moves forward without you.”
Your experience pushes you to agree? or disagree? I would love to hear your thoughts!
This article was originally published at oozou.com
Top comments (0)