Product teams have to do projects. It’s a fact of life. As much as we aspire to work as agile as possible, we can’t. The real world doesn’t work that way.
The good news is that, as a product manager, you aren’t wed to any one process. Your job, no matter how the work is framed, is about helping the team consistently make better decisions.
So, when the project bomb drops, don’t get angry, don’t panic, and most of all, don’t pretend that it isn’t a project. Project work is different from typical product work, and you shouldn’t think of it as such. If you do, your approach can backfire.
Not being clear about the type of work you’re doing has consequences. Teams begin to lose trust in you, the company doesn’t have clear expectations, and you, as the PdM, end up miserable. Stop that before it begins. Instead of holding onto process for the sake of process, where we just blindly follow what we were told, let’s talk about understanding whether you’re a project team or a product team and how to set yourself up for success to build trust whenever you’re in the project status.
Along the way, we’ll meet Bill, a PdM whose team got stuck with an exception, where he was given a project for the quarter. We’ll follow him to talk about how to set expectations for rightsholders and make the team stronger for it.
Product vs. Project Management: What’s the Difference?
- Product management involves empowering your team to operate independently and make better decisions over time. A strong product team controls its own destiny and is autonomous.
- Project management involves fulfilling a short-term goal in service of externally determined specifications and timelines.
Product and Project Management: What’s the Difference?
Marty Cagan talks about empowered teams, which has become the idealized state for product teams today. Empowered teams have the organizational trust to focus on solving problems, the resources to do so, and the clearance to operate as they see fit. He talks a lot about avoiding “feature factory” status, which he defines as a team that constantly produces things but doesn’t have a clear focus. This lack of focus leads to unnecessary complexity that slows down decision-making and operations later.
In an ideal world, all product teams would work in an empowered way. We know that isn’t the case, however. People always come up with projects in ways that we can’t refuse. When you’re working as a project team, you aren’t on that track at all.
You have a project, which is a task that is well-defined and with a clear due date. Projects also aim for quality. Quality, in this sense, means that you’re building toward clearly defined requirements. This is known as the specification. Further, outside forces fix the project deadlines, which flies directly in the face of an empowered team that is expected to set its own deadlines.
Bill knew this all too well. He sat with his boss, Jill, over lunch. It wasn’t a celebratory lunch, either. Jill had to give Bill a project that the CEO decided needed to get done. This project was a new feature that the CEO made a promise to deliver, and he gave the specification right to the client.
“I tried to fight for your team to continue on its current track, but the good news is that I got everything off your plate. Your team is now working on Project X, and it’s due in September.”
Jill knew that if a project is important enough to disrupt your roadmap, you need to make sure you indicate that it should be your priority. Projects that appear to be secondary never get done.
Bill looked down because he was nervous. Jill caught on and said, “I know this isn’t ideal. Have you had to make this switch before?” Bill shook his head.
“Well, let’s spend the next hour making a battle plan. Settle in.” Jill got a pen and paper out and began to give Bill a lesson on the spot.
How to Approach Project Management
Project work has to operate differently than product work. You are working on timelines and specifications in service of achieving a predetermined value. This differs from product work, where you’re chasing fluctuating value based on your company’s current strategy. Product work looks for outcomes; project work looks for quality. Quality, as defined earlier, is king. Everything else is irrelevant.
When a product team faces a new challenge, it’s easy for everyone to lean into the techniques that make the team successful. Product engineers are going to start thinking about setting up for the future. Product designers are going to think about extra usability improvements. All of this is well and good, but it’s not the work you’re doing when it’s project time.
You are thinking about specifications, and that’s it. Everything you do should be to understand the predetermined value and specifications. This is why it’s important to turn to the team and leverage their knowledge as you build a brief.
This brief, where you lay out what is important to the project, is the key to your team’s success. In it, you’ll talk to the folks responsible for the project and interview them as if you are interviewing users of your software.
Why?
Because the truth is, it’s a project. These things are typically one-offs. Bringing the ship into the harbor, even if it’s leaky, is worth more than making a beautiful ship that is still sailing when time is up.
In the interview, you’ll ask questions like:
Project Management Interview Questions
- What is the goal of this project?
- What are the non-negotiables?
- What are the important dates that we have to hit and with what artifacts?
- Is there anything we can cut in order to move faster?
- How often would you like to be briefed and what should that briefing look like?
- This project has stopped us from doing X. What’s the importance of this project so I can communicate it effectively?
These questions help create a plan and get clear on the quality requirements. The brief is the north star, and you need to complete it before you even start. Once you have the brief, not only will your team be on board (as they’ll have been with you every step of the way) you’ll have a really clear document to work from.
Bill recently finished his brief and presented it to Sarah, his design peer, and Alice, his engineering peer. Jill sat in the back and nodded quietly, watching the interaction between the three. Inside the brief, Bill laid out the expectations of the project – what are the specifications, the timelines, the rightsholders to consult, and what gaps in knowledge they have to solve to deliver the project on time.
One of the insights Bill got was that the rightsholders had time on Tuesdays to be briefed, and so he set a check-in for the team then. This meeting helps the team stay on what project management calls a critical path, which is the minimum requirements that they have to meet.
Bill smiles, “What do you think?”
Sarah and Alice both nod, and Alice says, “I understand this now. I can have the team get started and provide a timeline by Thursday. I can keep the things we need to cut in my back pocket and bring them to the next rightsholder check-in next Tuesday.”
Jill smiled. The team is getting a story together, and they’re aligned. This new way of working is starting to land.
How to Manage a Project
So you have a project. Check.
You have a plan and dates. Check.
Now you need to set expectations with the company beyond your team.
Instead of your agile rituals, you’re now sharing timelines. Instead of customers, you are talking to rightsholders. Instead of a roadmap, you live with a Gantt chart. You’re working in the world of projects, so how you communicate has to change to fit the new context.
You’ll also need to close up shop for your team by cancelling everything that isn’t tied to the project. This needs to be communicated through the organization. This may seem nerve-wracking at first since you certainly have standing about the work your team usually does. All that goes out the window with a project assignment. You and your leadership will have to communicate the change and the reason for the project. This messaging will help allivate tempers.
It also has a side effect — people will ask you to handle fewer projects. What you’re doing with this communication is making the pain public. A lot of leaders assign projects because they have no idea what they’re asking for. Making that cost public should give them an understanding of the gravity of the request. You’ll also gain trust for your team as you’ll be known for straight shooting.
Jill looked at Bill: “The CEO signed off on the project. Project X is here to help us compete in new markets. That’s the company line.”
Jill fills her afternoon coffee cup as Bill perks up.
“I’ve got that in the plan. In fact, I’m leading with it, as are Alice and Sarah. As questions come up, I’ll give them the standard answers from the rightsholders received from the original interviews and bring them up during our check in to keep everyone aware.”
Jill nods again as she sips her coffee.
“Good work Bill, Project X is rolling. Now comes the easy part — just ship it.”
Product and Projects Are Different — Handle Them Correctly
It’s important to know what kind of work we’re doing. Project work and prodcut work create different teams. Without taking the precaution to switch your team into project mode, you’ll find both the team and the project sponsor frustrated. When we’re put in this position as product people, we have to make the best of it. So, get the project right, nail it, and keep the trust you are building in the organization.