It’s called the “waterfall” process, and it’s a common method businesses use to develop new products. Clear and straightforward, it flows from start to finish along a designated path, with minimal distractions and an internal logic all its own.
There are six phases to the process, according to Marty Cagan, author of “Inspired: How to Create Tech Products Customers Love.” They are: “Ideas, ‘Biz Case,’ Roadmap, Requirements, Design, Build.”
Want to learn more? Cagan would be glad to teach you—as long as you keep the waterfall process as an example of what not to do.
Building ‘the Wrong Thing’
What’s wrong with the waterfall process? Cagan’s book explains this in depth, but for a succinct, one-sentence summary, listen to Kelly O’Connor, a product manager at the United States Digital Service who will be teaching the inaugural course this fall for Georgetown University’s new Certificate in Product Management:
“There’s no point in delivering something on time and on budget if it’s the wrong thing.”
In the for-profit world, “the wrong thing” is something that, for whatever reason, people won’t buy. In the realm of government, where O’Connor has shipped numerous digital products being deployed by the U.S. Department of Veteran Affairs, it is something that doesn’t help them complete a task or solve a problem. In both instances, the critical missing element is user input or human-centered design (HCD), which focuses decisions about design and functionality on the people who will actually be using the product.
Among its many failings, the waterfall method all but ignores customer input until far too late in the process. Typically, what happens is this: A team brainstorms, posing questions such as “What would our users want?” or “What would the users do next?” But by not involving the users themselves, the team is basically speculating—and postponing much of the risk until the end: If the team guessed right, the product succeeds; if not, well, it’s too late in the game to correct it.
This process also runs counter to the relatively recent use of minimum viable product (MVP), whereby designers start small and deliver the smallest thing that provides value to the user in order to get feedback and test hypotheses and assumptions.
Delivering What People Want and Need
As a profession, product management has been around for at least two decades, but it is increasingly relevant now, in an age of rapid digital innovation. In today’s fast-paced environment, where needs constantly change, discerning what the customer needs at multiple points during product development is critical to a product’s success.
People are often confused by how product management differs from project management, so they use the terms synonymously. This is a big problem, O’Connor said, because they are different disciplines requiring different skill sets, methods, and tools.
Project management is “plan-based,” focused on delivering a product on budget and on time, O’Connor said. It is concerned with coordinating complex variables such as the scope of the project, budgets, personnel, risk, communication, and schedules. It is document-heavy and often views user feedback as “scope creep.”
Product management, by contrast, is “user-based,” focused on developing a product that the user wants or needs. As such, it should involve users throughout the process, not simply at the end. Their input helps create prototypes that are quickly designed and tested—and revised and tested again.
“Small, empowered teams actually go out and talk to users,” O’Connor said. “You want to launch your MVP to users as soon as you can. You can’t do HCD if you don’t ever leave your desk.”
The federal government lists hundreds of jobs for project and program managers, but very few, if any, for product managers, O’Connor said. But often, these professionals have to build and deploy products even though their job descriptions detail only traditional project management skills. And while these are essential skills, to be sure, they do not reflect the responsibilities of both professions today.
At the same time, this traditional view of project management is changing with the adoption of principles such as Extreme Programming (XP), a component of the Agile software development process that emphasizes test-driven development, small releases of products, working in well-organized teams, and continuous integration of any new features they may have developed.
Designing for the ‘Read World’
What, then, is program management?
“Program management is like running a university,” said Craig Butler, senior software manager at Ad Hoc LLC. Other examples, he says, are publishing “a newspaper, maintaining a diet, keeping a garden—something you have to keep going.”
Product management also requires you to “keep going,” but here it means reengineering products for a changing market.
“Now, with web applications, you’re never finished,” Butler said. “They’re always changing.”
Butler teaches the engineering-centered course for the Product Management Certificate, and another course focuses on design issues. He said he wants, as much as possible, for his class to simulate the dynamic, real-world environment in which product managers work.
“Let people act as if they’re going to start a new job on Monday,” he said, “and they’ve got to know what they need to know and go ahead and start doing it.”
O’Connor also stresses a simple and direct approach.
“Go out to where your user sits, and watch how they use your product,” she said. “It’s as simple as that to get started.”