There are a lot of different ways to attack the gap in a stagnating product, but one suggestion I always make is to think about checking your product development approach, if you have one, and making sure it’s an actual product development approach.
Product Management or Project Management: What’s the Difference?
Product management starts with the customer needs and blends those needs with company goals to perpetually enhance and add features that increase value for existing customers and attractiveness to new customers.
Project management happens when the business decides the requirements of the product outside of input from the development team, sometimes even without the customer, then hands off those requirements to a project manager, who works with the development team to understand the requirements, set the deadlines and manage progress.
When is it not? When it’s a project management approach. To home in on the difference, let’s jump briefly into the history.
SaaS and the Advent of Modern Product Science
SaaS didn’t necessarily usher in the mainstream acceptance of product science, but it definitely accelerated and evolved it. SaaS required product-adjacent elements from marketing (key benefits, engagement) and engineering (UX, UI) to exist on their own in a space that sat between the customer and the product itself.
Before SaaS, computers were mostly desktops and were almost strictly used for business or gaming. Sure, there were occasional releases of productivity software meant for the general public on home PCs and laptops, but it wasn’t until the 2010s when we started to see the browser as the OS of choice for any kind of application — business, personal or otherwise.
Eventually, that OS became the mobile browser and the native mobile app.
This meant that any digital product now had to conform to what was called mobile-first design. An application developer now had to assume that their user:
- Was going to run the app on a phone.
- Wasn’t at all a technical person.
- Wasn’t already well-versed in what the application did.
- Wanted to minimize their time with the app while the maker of the app wanted to maximize engagement.
Those are unflinching, even conflicting, requirements.
Mobile and the Evolution of Product Management
That last two of those assumptions are key, because they’re the reason why mobile UI became mobile UX. Apps and software used to be designed for a very specific audience. Well-designed UX and UI were pretty much nice-to-haves, and engagement didn’t matter.
As mobile adoption exploded and the software user base started to grow and change, it begat the modern science of product management (company goals, use cases, customer success), which sits between product engineering and product marketing.
Before product management became its own thing, its spot in the middle was often occupied by project management.
What Is Project Management?
Project management happens when the business decides the requirements of the product outside of input from the development team, sometimes even without the customer, then hands off those requirements to a project manager, who works with the development team to understand the requirements, set the deadlines and manage progress.
From a hindsight point in 2023, this is a terrible way to build things. But it’s what we did in the long-ago, and many companies and even startups still run with project management and call it product management.
A lot of companies just use “revenue” or “profit” as the goals that the product is trying to achieve. But this is like chasing a rainbow by smell instead of by sight.
When product management is just project management in disguise, it usually eschews product engineering and product marketing, and also everything about connecting the features of the product to the goals of the company. To substitute, a lot of companies just use “revenue” or “profit” as the goals that the product is trying to achieve. But this is like chasing a rainbow by smell instead of by sight.
In other words, just because a product makes money or is profitable in the moment doesn’t mean it’s going to stay that way in the next moment. This is especially true in technology, where the reasons why something makes money or is profitable can change from week to week.
Product science requires thinking far ahead in the engineering cycle, and also getting close —very close — to the customers on the success and marketing side.
So to make the shift from project to product, the first thing you have to do is set the product role on both the business side — helping determine the business needs and the customer needs — and also on the engineering side — turning those business needs into functional and even technical specifications.
No more waterfall software development. And in fact, the product team should even be closing the feature circle, delivering the finished features to the customers and getting their feedback on how the new benefits not only works for them, but also how it changes their needs.
What Is Product Management?
The next big shift is to stop thinking in terms of project plans and start thinking in terms of the broader product roadmap.
When the product roadmap is prioritized to the company goals and the customer needs, deadlines should be placed on revenue expectations and customer benefit, not individual features and enhancements. These priorities should map all the way back to those business, function, and technical requirements.
Project plans are usually built based on business needs, which come from the business side and focus on what the product should do, not what the customer needs. When that happens, entire chunks of functionality — features and feature sets — expand what the product can do, whether the customer needs it, will use it, or will ignore it.
Product management starts with the customer needs and blends those needs with company goals to perpetually enhance and add features that increase value for existing customers and attractiveness to new customers.
The former pleases executives, investors and board members. The latter pleases customers, which encourages sales and revenue, which pleases well…executives, investors and board members.
The difference is in the deadlines. Project plans usually have deadlines of months or quarters or even entire years worth of work to produce the final deliverable. A product roadmap does the same, but releases priority functionality, based on customer needs, perpetually over sprints, usually every two to three weeks.
I wrote a post about four years ago calling for the end of software development deadlines. I got roasted. But that was just a call to replace project management with product management, only from the developer’s point of view.
Once you adopt these two big changes — a broader approach to the scope of development and a shift from project plans to roadmap — the rest of it becomes pretty clear. You can lean on Agile or something like it to bring the process into reality, but you don’t need to swear by it.
