You are smart and competent. You work in some department, for some organization that requires innovation. Maybe it’s a content publisher, or a manufacturer of medical devices, or a legal services firm. Something like that.
So you and your team come up with this idea for an innovative thing. The thing is digital, social, mobile, and it will revolutionize how you find and acquire customers—plus millennials will love it. Something like that.
As you develop your idea, you get input from all the right holders of all the right stakes. You propose an initiative and present to a committee. You fill out a form.
You talk to IT; they want high-level requirements, so they can make estimates, and then they tell you that it’s gotta get behind something related to a CRM project or something.
But that’s OK, you are smart. You are competent. You won’t be discouraged. You fill out another form to keep your project dream alive.
Someone advises getting outside help, so you visit a digital agency in a cool part of town. You note they have the exposed brick, funky eyewear, and ironic facial hair required to be makers of things like this.
So they are happy to make your idea a thing. They show off a gorgeous presentation–one thing these people do really well is make great slides–with an inspiring vision. It is bursting with breathtaking diagrams, and dangling a breathtaking price tag. You change a few priorities, procure more budget, and sign a deal.
And then the project begins. You burn up the next few months dealing with timelines, budgets, resources, estimates, requirements, mock-ups, wireframes, APIs, code: all the deliverables, an ugly noun that started life as a perfectly fine verb.
All the while, you are defending your project’s budget, keeping your leadership informed of progress (“we’re back to green!”), anticipating what might go wrong, counting down to completion.
There are tense moments, and a couple times you need to change requirements and even adjust timelines, which is harder than you think it should be, but, finally, probably on a Thursday morning (never a Friday), the big day hits: launch day.
It’s a glorious day. The app, microsite, system, whatever it is goes live. You feel like a general who has just orchestrated a marvelous, daring operation.
You hit “send” on a launch announcement email, CCing the right people, praising everyone for their work. Responses roll in. “The app looks great!” “Great job getting this thing to the finish line!” “Really nice execution. And it looks AWESOME!!!”
You enjoy a celebratory happy hour with the project team on the agency’s dime. You update your LinkedIn profile. You’ve successfully navigated the project gauntlet. YOU are a hero.
But wait, are you really a hero?
To be clear, it’s a great story, and certainly you are smart and competent.
But read the story closely and you’ll notice a giant dollar-shaped hole in the plot: We never know if all that effort, all your heroic work, actually did anything to please your users, readers, customers, constituents.
We never discovered if that investment of time and money contributed to your organization’s mission and goals.
Now, the problem isn’t smart, competent you; it’s that you are operating in a context where the mechanisms of the project obscure the reason for the project.
Your project’s purpose should be to solve your users’ problems in a manner that contributes to your organization’s mission. Distilled: to produce value.
Fortunately, because you are smart and competent, you can change this. How? By orienting your innovation work away from projects and towards the product itself.
Here’s the difference: A project is an organizing construct for internal labor. A product is a thoughtful response to a human appetite.
Customers aren’t delighted by your organizing construct. They don’t want your budget or timelines met. They want their problems solved, their needs satisfied, their lives improved.
When you manage the product, you will naturally start with deeply understanding your users. After all, how can you respond to a human need without knowing that much?
When you manage the product, instead of prescribing a team to execute a grand vision, you will empower the team to solve problems or satisfy opportunities by discovering solutions.
If you’re able, you budget accordingly, for the team and their talent, rather than for features and functions.
When you manage the product–and this one’s difficult!–you’ll rethink your organization structure.
If you can, you’ll pull the product-making out of IT and into a product design and engineering organization. Your beleaguered IT gang is trying to keep the business operating efficiently, not to make value.
When you manage the product, you’ll design your processes to uncover and then respond to new insights.
You’ll know you’ve done this well if you celebrate, rather than bemoan, a change in requirements: it means you know more.
You’ll realize that estimates are guesses, and expect the appropriate precision.
You’ll make small things first, and get them into the market quickly. That idea you have? The first thing to do is learn whether it is any good.
So deliver the smallest, cheapest thing you can that will teach you that. If your idea isn’t worthwhile, be glad that you found out quickly.
You’ll measure relentlessly and listen intently. You’ll adapt based on what you learn.
You’ll recognize that doneness happens constantly and never. You will still enjoy happy hour with the team, but the occasion will be celebrating the value you’ve made, not the release you’ve delivered. If Amazon.com’s engineers celebrated every release with a happy hour, they’d be drinking every 11 seconds.
Most importantly, when you manage the product you’ll shift your goals from inward to outward, from the success of your project (your timeline, your budget, your idea) to the satisfaction and delight of your users. You’ll edit your tale so that they, not you, are the heroes.
I can’t wait for the remake.
This is a reprint of a post I wrote in 2015 while working with the fine folks at GoKart Labs, a business innovation, design, and strategy consultancy. Reposted here with permission. You can find the original here.
This post has also been featured in Bruce McCarthy’s One Thing Newsletter, a bulletin on Product Culture.