Product vs Project: How They Differ, and Why Elon Needs To Learn It Fast

You say tomayto, I say tomahto. You say project, I say product.

To many people, the only difference between project thinking and product thinking is two letters. The two terms are often used interchangeably and the abbreviation “PM” could refer to either one of them.

Even I’m guilty of it; if I have to explain my job to someone outside of tech, I usually go with “Project Manager”. It’s a term that even my mum understands. Product Manager? That’s a conversation that I might regret having with her when I’m still explaining it six hours later.

But for the teams and leadership creating digital experiences, knowing the difference is critically important. It’s a distinction that can change a company’s whole approach when it comes to creating new products and services. Getting these terms muddled or deliberately misusing them is a recipe for confused outcomes and demotivated teams.

Here’s how I see it. If the primary aim of a project is to be completed, then the primary aim of a product is to create value. When viewed through this lens, it becomes clear that project-centric teams and product-centric teams will have different motivations, employ different strategies and produce vastly different outcomes.

If the primary aim of a project is to be completed, then the primary aim of a product is to create value

If a team’s primary focus is on completing features handed down by leadership, dictated by sales or even suggested by users, they are project-focused. It doesn’t matter how many Product Managers, Product Owners or Product Strategists they have on the team – at the core the team is project orientated.

In this post, I’ll lay out how true product-centric teams focus on creating value for the end user and the business. I’ll also have a look at when product and project-led approaches can be most effective, with the help of some terms you probably didn’t think you’d read in this post: clouds, clocks, and that guy, Elon Musk.

Defining product vs project with job ads

First let’s start where the definitions of project and product are most obvious – job titles.

Below I’ve documented a couple of ads that I’ve seen out in the wild that capture the essence of the roles well.

I must say that these took a bit of finding. Since product and project are two concepts so misunderstood and misused (sometimes deliberately), there were plenty of ads that were advertised as a product role but sounded an awful lot like your traditional Project Manager.

We can put some of this down to ignorance about the difference, but some of this is clearly due to “product” being a more exciting proposition for job hunters these days (read: it’s in fashion).

Project manager

• Planning and coordinating the activities within the department, for projects involving multiple products
• Ensuring all requirements from a functional perspective are collected and prioritized
• Involving the technical counterparts to anticipate dependencies and manage risk
• Ensuring that projects are delivered on-time, within scope and within budget
• Managing stakeholder expectations on milestones and deliverables for complex digital projects

Here we have a pretty dead-on Project Manager description.

A Project Manager’s primary job is to keep things running to schedule, on budget and co-ordinating the different people involved. I do have my reservations about the stipulation of “delivered on-time, within scope and within budget” (rarely can you have all three of these at once in my experience), but if that’s the way Frontiers develop their software, then at least the ad is transparent about it.

The measure of success is clearly stated here – “Ensuring that projects are delivered”. It’s the Project Manager’s job to take the specs and deliver them as software without asking too many questions about whether what is delivered is actually valuable.

In fact, you’ll notice that there is no mention at all of getting involved with anything post-delivery (e.g. measuring if what the team has delivered is being adopted). This is a good example of how a project-centric team works – do the job, get it out the door, move on.

Product manager

Now let’s look at a Product Manager role at Paddle. (Source: (Senior Product Manager - Payments)

• Identify opportunities: Work closely with Marketing, Product Design and Sales to gain a deep understanding of customer needs and the market landscape. Identify product gaps and prioritize and design features for a variety of personas.
• Shape the roadmap: Use internal and external analysis to take a lead in generating a vision for the strategic direction of the product roadmap and wider business, always ensuring Product & Engineering is making the right impact. You’ll lead small project teams, providing direction & keeping stakeholders engaged. You will also be responsible for determining key milestones.
• Ship value often: Work with engineering and design; and develop appropriate planning, prioritization, and delivery processes to enable the launch of new features and products that deliver fast value to our software sellers. Lead effective discovery of new initiatives, run agile workshops and facilitate prioritization conversations.
• User Testing: Make use of usability and beta testing to ensure our product offers the best user experience and meets customer needs.
• Measurement and reporting: Analyze the performance of our product using data, and use those insights to determine the product roadmap. Based on product performance, determine when actions are needed to upgrade, improve, revise or reposition products.

Do you notice some of the terms used here?

“Ship value often”

“Ensure our product offers the best user experience and meets customer needs”

“Analyze the performance of our product using data”

There is no mention of delivering for a certain deadline (other than ship often) nor mention of a fixed scope (other than identifying product gaps and prioritizing).

This is in stark contrast to what we saw in the Project Manager role. Here, deadlines and scope are not fixed constraints and they are certainly not a measure of success. As such, they become irrelevant to include in the job ad.

Instead what we see is a focus on discovering opportunities, delivering often and measuring the results. The job is about learning what customers will find valuable and quickly testing out whether we’ve implemented it in a way they will adopt it.

Paddle’s ad demonstrates that a Product Manager’s time and energy should be spent making sure the software delivers maximum benefit for the customer and the business.

If you see a product job ad where “delivering” seems like the key measure of success — beware — because you’re most likely looking at a Project Management role in a project-centric organization (whether the organization knows it or not).

Unfortunately these seem to be all too common as companies compete for talent. A true Product Management role is much more intellectually interesting than a project role, so there are plenty of project jobs dressed up as product jobs. Read the descriptions carefully!

A project-centric approach has one big weakness

Based on those job descriptions and some personal experience, let’s dive into what software developed by a project-centric team might look like.

Imagine you’ve been asked by senior stakeholders to create a new app that connects reviewed and vetted local window cleaners to people who need their windows cleaning. Think Checkatrade for dirty windows. Not exactly groundbreaking but bear with me…

The stakeholders believe they spotted a market opportunity and are ready to capitalize on it.

They want to make an app and want it to start making money as soon as possible.

However, there are some constraints. ”We’ve got a budget of $250,000 and it needs to be launched in time for the new year” – 4 months away.

We’ve also been given a list of features that our app must have – “the backlog”. If we can launch this app in January without blowing the budget, we’ll get a pat on the back.

In many ways, this approach makes a lot of sense. The budget and timeline are genuine constraints and the list of features that we’ve been given seem to be well researched. Our job, as the people tasked with building the app, is to get it done.

Success is measured by timeline and budget, not value and impact. This way we can direct all of our focus on building the software, and not worry whether we are creating something that customers will actually adopt. That risk and stress sits with the senior stakeholders that we’re taking requirements from. Sounds great right?

Well in certain contexts, this can work very effectively. However it does all hang on one thing. Can you see it?

The big assumption with this approach is that the requirements provided by senior stakeholders match up to our customer needs. To put it bluntly, we decided what would be valuable for users or the business at the start of the project, and the hope is that we are correct.

Of course, we might get lucky and ship something that truly is a hit. However there’s a big risk that we’re plugging four months of expensive development time into a product that our customers just don’t care about.

Worse still, there’s no formalized process on measuring if they do care about it or not. This leaves our roadmap at risk of becoming a list of opinion-driven features rather than following a strategic vision (read Escaping The Build Trap for more on this topic).

But as a project-driven team, we’re not incentivised to care. We’ll just get our heads down, build it, and move on to the next project.

Broadly speaking, we’re not sure whether our users will find our project valuable, which in my opinion, just isn’t a good approach.

At best, it’s an unnecessarily risky approach that has a high chance of delivering a load of code that nobody wants.

It’s also unlikely to get the design and development team particularly pumped up about the project. Making a product with the aim of “finishing it” isn’t very motivating.

On the contrary, making a product with a goal in mind, watching and measuring how people interact with it… Now that has some intrinsic motivation attached to it.

Clouds, clocks and birds – when to use a product vs a project

A project-centric approach can produce good results in the right context. Things have been produced like this for centuries after all, so it can’t be so bad.

It all comes down to the type of product that we’re building. Is it a cloud or is it a clock?

Spawned from an essay written in 1966 by Philosopher Karl Popper, the cloud and clocks comparison tries to categorize problems into two types:

• Those that are reliable, predictable and orderly
• Those slippery issues that are irregular, disorderly and less predictable

Clocks

Clocks are problems where the answer is obvious and success is easy to evaluate. If we want to build a clock, as long as we follow the instructions correctly, we’re sure to produce something of value.

You make a clock, it tells you the time and this is a pretty simple problem if you have clock making skills. The road to success is therefore in the execution. It’s also easy to measure if we’ve done a good job – the clock either works, or it doesn’t.

Clouds

In contrast, clouds are complex systems that are made up of multiple parts interacting with one another, often in unpredictable ways. The road to success here therefore requires taking the time to understand these interdependencies better and accepting that the system will contain many unknowns, especially what delivering value looks like.

Clouds are messy things – the goalposts are always shifting as the various interdependencies evolve. Ben Sauer sums this up nicely on Twitter (and applies it very well to Twitter’s direction under Elon Musk):

Here Ben points out that building self landing rockets and electric cars are very much clock problems – a rocket lands on the pad or it doesn’t, a car drives or it doesn’t.

A social network? That’s more tricky to pin down; you’ve got complex webs of social interactions that need to be moderated fairly, customized to each user, ranked by importance; all at the same time as remaining interesting and engaging enough for users to keep coming back and corporations to keep paying for ad space. It’s complex stuff.

Shreyas Doshi follows in the same vein by pointing out that Twitter is looking pretty project-centric with the introduction of Musk. And the way he lays it out, it’s hard to argue with that conclusion.

As he asserts, since Musk’s arrival, Twitter has shifted to being run in a project-orientated way; focusing on outputs and heroics rather than outcomes and insight-informed decision making.

By approaching a cloud problem like Twitter in a reductionist, project-led way, Musk runs the high risk of producing a load of stuff that sounds great around a whiteboard at 1am, but in reality nobody needs.

Twitter’s problems are complex and forever changing and the “product” concepts on the right side of the above table will be most effective in tackling them.

Use a product-led approach for cloud problems

As exemplified in the Twitter example, cloud problems are best approached with research, experimentation and iteration. Since we can’t be sure what value looks like, or even if it will remain a constant, the best approach is to probe, measure the results, and probe again. This is why methodologies such as agile or lean product principles bring so much success in this field.

Most problems solved by new software being created falls under the cloud category. At least when working on new, innovative products, we’re usually working on issues that are messy and complicated. It therefore makes the most sense to use a product-centric approach.

Use a project-led approach for clock problems

If the most important question is “when?” as opposed to ”why?”, a project-led approach can be useful in the right context. That is, when dealing with a clock problem.

There are still plenty of clock problems out there that need to be solved. For example

• A factory that is churning out widgets
• A housebuilder that is building thousands of homes in a tried and tested design
• A software project where: * You’re working directly with the person that will use it * You’re replicating an existing tool

Elon Musk might well find out that he’s tackling a cloud problem with a clock approach.

Moving your company from project-led to product-led

Now that you’re clear on the principles of product and project and when to use them, hopefully you’ll be motivated to start using these approaches on future software experiences that you’re involved in creating.

But hold up, what happens when everyone in your team is not as clued up as you?

There are many organizations out there operating under a traditional project approach, or mistakenly thinking they are product-led when in reality their Product Manager is just taking feature orders from the top. It can be hard to change the approach, even if you want to.

However it is possible to inch your way towards being more product-centric. You might have to introduce these tools and concepts slowly, and you don’t even have to mention the change of approach, but bit by bit you will start making the shift by implementing some of the below.

Start at the problem before designing the solution

Investigate the problem where these requests are coming from, frame the objective and how you’ll measure success, and then come up with the feature ideas (by all means involve the business and customers in this process). This way you’re much more likely to focus on developing solutions based on solving real customer problems.

Objectives and Key Results

Use OKRs where appropriate. Used well, OKRs can help you stay focused on measuring value rather than output. This is a key facet to becoming product-driven and makes sure that success is measured by customer value, not deadlines or features to please stakeholders.

Recognize and test your assumptions early and often

Assumptions mapping can be a great way to keep you questioning if your customers really do experience the problems that you’ve identified and if they will find value in the solution that you have dreamed up. Combined with running experiments such as interviews, smoke tests and prototypes you can test if the solutions you’ve identified really do create value for your customers.

Move to a product-centric roadmap

A now, next, later roadmap can keep you focused on solving problems, rather than working through a wishlist of features. It keeps you focused on the most important problems to solve and can be a good way of structuring your product in a way that favors outcome over output.

Don’t assume the user is always right

Don’t fill your backlog with ‘bright ideas' from customers or inside your business. This might feel like you are taking on a product approach (listening to feedback and iterating on it), but you’ll quickly find yourself with a roadmap of tactical features, not a product strategy. To quote Henry Ford: “If I had asked people what they wanted, they would have said faster horses”.

Conclusion

Being product-led suits teams that are focused on delivering value to users, rather than being fed requirements from management or other sources. There is a much greater focus on the “why” and timeframes for delivery are less of a concern compared with the outcome that is achieved.

Being project-led is perfect for teams that are working within strict time constraints and have a very clear idea of what the final deliverable needs to be. The focus is placed on the “when” and “what”. This approach has a serious danger of missing the mark if the value to the user is not very clearly known.

Armed with this knowledge, as well as the two distinct types of problems, you should be able to start producing software that is more valuable to users, more profitable for your business and more motivating to build for your team.

Let’s hope Elon reads this post too.