Rakesh Malhotra October 25, 2018
When I used to interview Product Managers/Program Managers at Microsoft who came from professional services backgrounds, I would make it a point to always ask “what’s the difference between building a solution for a customer and building a product at a software company like Microsoft?”.
I had gone through this transition myself and was curious to understand other perspectives. Some candidates would be quick to draw parallels between the two situations, eager to point out how their experience would be quickly transferable. In both cases, you will collect requirements, put together an agreed-upon plan, execute, deliver, gather feedback, and iterate. This is all very true and reasonable. The really thoughtful candidates, however, would focus on the differences and appreciate the fact that these differences were far more profound than trivial semantics.
As part of a successful digital transformation initiative, business and technical leaders within organizations also need to appreciate this difference and move from a “project” to a “product” mindset. There are layers of ways to unpack this statement but let’s walk through a few key ones.
Output vs Outcome
Most projects have a specific set of deliverables that are painstakingly enumerated. While it’s presumed that these deliverables will produce the desired business outcome (this is usually validated at the beginning of the project), there really needs to be continuous re-calibration of the deliverables to the outcome. When this doesn’t happen, the team tends to focus on producing the deliverables (the output) at all costs and treats their delivery as “success”. A change to the deliverable list requires bureaucratic gymnastics and each stakeholder tries to internalize the impact on their own team rather than the overall outcome they are trying to achieve. In product organizations, simply building what you set out to deliver is not nearly sufficient to claim success. Good product teams are measured on the business outcomes they deliver, not the checklist of items each team churned out on time and on budget. Timelines and budgets are obviously important but nobody cares if a poor product is delivered ahead of schedule.
Solution vs Mission
Projects tend to be focused on solving a very specific set of problems. They are often called “solutions” for this very reason. Products on the other hand are tied to a longer-term mission which might not even be theoretically achievable. As a result, great products are never truly finished. As any experienced product manager will tell you, if you’re not at least a little ashamed of your latest release, you’re probably not holding yourself to a high enough bar. Solutions also tend to focus on a fairly narrow set of target users or customers i.e. those with the problem that this solution is intended to solve. Missions might start with a tightly defined target but only as practical consideration as part of a much more ambitious plan. Delivering on a mission also involves a much broader effort than simply delivering high-quality code. It involves investing in the go-to-market mechanics, driving adoption, training, support, marketing, evangelism, ecosystem development, community building, etc.
Ownership vs Influence
Some organizations have autonomous teams that can fully execute and deliver on all required elements of a business outcome, but most are not structured this way. With a project mindset, this isn’t particularly important because you can simply assign tasks and deliverables to stakeholders and owners across teams and hold them accountable for delivery. You might set up a “PMO” office to help facilitate this and other such initiatives. Using a product mindset, you’ll find that influencing others and driving (not collecting!) a consensus is critical to success. Product teams try to control as much of the outcome themselves as they can but they also create meaningful partnerships both within and outside of their organizations. They often have to hedge their bets and make a clear business case to justify their requests of others. They get what they need not by executive order (a last resort), but by building credibility and influence through a track record of making good on promises and, as they say at Amazon, “being right a lot”. Don’t get me wrong. I don’t mean to imply that product-oriented teams don’t need deliverables, discrete problems to solve, and buy-in from top executives. These are all important but product teams view them as tactics in support of a larger outcome and grander mission. Companies looking to recast themselves as software-driven organizations should look to adopt these principles as part of their transformation journey.