Product Thinking vs. Project Thinking
One of the biggest challenges a product manager will face (or an organization for that matter) is trying to elevate thinking and culture from a project level to a product level.
Project Thinking
Project thinking is fairly pervasive. Many folks, especially in software development, have spent a lot of their careers focused on projects and project management. Large organizations often have PMO departments, focused exclusively on project management. It’s not surprising, because project management has been around a very long time. And we as humans tend to think in terms of projects: things we need to get done.
So what is project thinking?
The focus of project thinking is delivery. This could be the delivery of specific features or software, or really the delivery of anything. From aircraft to houses. And because the focus is delivery, the primary measurement is on the timeline and schedule. Project management is specifically focused on the output, and is measured by how accurately we were able to estimate the timeline beforehand and then deliver the specified output on that schedule. Success is largely defined as taking the specs of something beforehand, setting up a schedule with milestones all along the way, and then hitting those dates.
Product Thinking
Product thinking takes a fundamentally different approach. Rather than focusing on the output, product thinking is focused on the outcome.
This is a significant shift from the mindset of project thinking. Rather than focusing on timelines and dates, we focus on the goal we want to achieve or the job to be done. Because we’re focused on the outcome rather than the output, it is much more difficult to put time constraints around the delivery, at least up front. Primarily because we don’t necessarily know how we’re going to accomplish the goal up front.
This kind of thinking can be quite the shift, especially for folks who have spent a lot of time focused on projects and project management. Many people are uncomfortable with the uncertainty of not having structured timelines and schedules that they can monitor on a regular basis.
The Benefits
So what are the benefits of letting go of project timelines in favor of focusing on outcomes?
First of all, it is ultimately the outcome that we are driving toward, regardless of how we try and get there. The main benefit of a product mindset is that we ensure that we get to the outcome more efficiently.
With a project mindset, we assume at the beginning that we already know how to achieve the desired outcome. Working from that assumption, we create a project plan and timeline full of the requirements and milestones, and then begin execution on that plan. If we’re right, and what we assumed initially turns out to be the right solution, then we’re in great shape. We just execute the plan and achieve the outcome.
But what if we were wrong initially? What if the solution we identified isn’t going to achieve the outcome we had hoped?
That is where project thinking gets us into all sorts of trouble. Once we set a plan in motion, it can be very difficult, especially in larger organizations, to pivot and change. Once dates have been put in place and everyone has agreed on a plan, that is usually what sticks in everyone’s minds, despite our best efforts to learn and adapt. And if we end up missing a date, it can cause incredible issues for teams and businesses.
But with a product mindset, we are able to learn and adapt as we go. We aren’t set on dates and milestones, but rather are focused on learning and achieving the outcome. If something doesn’t work out or customers don’t respond well to one thing, we can take that into account, adapt, and still work toward the outcome we had intended without blowing up a beautiful plan that is everyone’s focus.
Crucially, when problems arise (and don’t kid yourself, they always will arise), product thinking allows us to learn and adapt, and stay focused on the outcome we’re trying to achieve. In contrast, when problems arise and we’re stuck in project thinking with its focus on the timeline, we will often get sucked into endless meetings trying to determine why our initial guesses were wrong and how do we get back on schedule. This ultimately leads to sacrifices in quality, work-life balance, and the outcome since we need to stay focused on delivering the output we initially agreed on (regardless if that is still the right thing to do).
A Project Example
We’ve been talking about a lot of concepts, so let’s take a look at some examples to better illustrate these points.
A great example of a project is the construction of a house. My wife and I built our house last year. We went through the whole process of selecting the floor plan, choosing all the finishes and details in the house, and then paying large amounts of money to get it going.
When we started, our construction manager (who was absolutely excellent), gave us the estimated finish date. It was about 6 months in the future. Obviously there are many things that go into these estimates, and things often come up that throw the dates off, but since the construction of a house is a very repeatable process with defined inputs, a good construction manager can look at the plan week by week and determine when they expect to complete the work.
Our house was off by about a week, which feels like a bulls-eye in my opinion. One of the trades was delayed in getting their work done, so that set things back a few days, which had some ripple effects. But that is fine. It’s expected.
When it comes to these types of construction projects, they are very much geared toward project management. Everyone knows what needs to be done and keeping people on schedule is a real key, especially since it wasn’t just our house being worked on, but the whole development.
A Product Example
But does this kind of project management work everywhere?
No, it doesn’t.
As much as we’d like to think of software development as construction, it isn’t. The clearly defined plans and work don’t translate to product development no matter how hard we try. While there is great comfort in well-defined timelines, that’s not how we should do product development.
In a product I’ve been working on, there is a key problem I identified and knew we needed to solve in order to continue to broaden our audience and reach additional users. The traditional approach to this would be gather the requirements, scope out the work, and then build the features. But much to the consternation of many folks at my organization, I don’t take that type of typical approach.
Once I understood the problem, I dove into researching solutions, from building the features to integrating third-party software. As I did this, it became apparent to me that the solution was, in fact, not to build anything. Rather than build new features or integrate someone else’s software (in this case, it was a portfolio for students), the solution was to change what we were asking students to do. Rather than focus on the portfolio tool, we could simply ask them to create the portfolio pieces and then utilize whatever software solution they wanted to in order to showcase their work. The benefits to everyone would be significant. Students would be in control of their portfolio, and we wouldn’t be tied to building software or using any specific vendor.
We would have never come to this solution with project thinking. This solution came about because I was focused on the problem and the outcome (getting additional users on our application) rather than building the next feature.
This type of result is typically the outcome of product thinking. And it can come at any point along the way. In my example above, we avoided doing any development work. But often it may take several design prototypes to figure out what will work. Or we may do small amounts of development work in learning what features will truly drive the outcome we want. No matter where in the process we learn, the key is that we are learning along the way rather than deciding on the course up-front and following a project plan.
The Right Way
So how do we do that? How do keep a product focus?
All products and product management involve some level of project management. We have to keep things moving along and it is (unfortunately) unrealistic to assume that we can work in environment where our stakeholders and partners won’t expect some dates or commitments.
The key is to make commitments and project plans only at a point when we can do it with a high degree of confidence. So rather than committing to a specific path beforehand, we commit once we’ve validated what we’re doing and have had a chance to really understand what it will take. Often that is a sprint or two into the work. That may feel really late in the process, but it is at the point when estimates and plans can actually mean something. Marty Cagan, in his book Inspired: How to Create Tech Products People Love, calls this type of commitment a “high-integrity commitment.” We allow teams time to do proper discovery and research before asking for commitments.
And we also need to help others realize the benefit of product thinking. There is a reason many folks ask for dates and timelines. Part of it is because of old habits. But there are times when it is necessary for business and budgets. So we need to understand what the job of the timeline is in those cases. If it is to help sell the product, we should turn the focus from specific features to the higher level story. If it is to manage risk, maybe we need to help folks understand that the real risk isn’t missing a date, it’s missing the mark completely on what value we’re trying to deliver.
At the end of the day, the whole purpose of product development is to deliver value to users and customers. Most of the time we don’t know exactly what is going to deliver that value though. To think that we can come up with the right solutions up-front, sometimes a year in advance if you do annual planning and budgeting, is pretty unrealistic.
While project thinking focuses on coming up with solutions up-front and then delivering against a schedule, product thinking keeps the focus on the outcome. That involves some level of comfort with uncertainty and learning, which can be pretty hard. But if we want to get to the right outcome, and not just an on-time output, it is really the only way to work.
You can follow me on twitter here:
Subscribe to my new product newsletter here:
You can check out our product podcast here:
