Moving from Projects to Products

Understanding the difference is critical to business success. Don’t believe the similarity in the words means a similarity in the concepts or how to operate your business.

TL;DR — Moving from a project to product focus is a significant change for any company.

For companies that are Project-focused — e.g. an agency, IT organization, consulting company, or a technology-enabled services company — the entire organization — leadership & staff (skills and roles), processes, org structure, compensation, business model etc. — has been built to deliver on those projects, on time, on budget, or by whatever metrics are meaningful.

When trying to become Product-focussed, the company or organization needs to rethink it’s roles, skills, processes, incentive systems, and especially business model. to create a different company that delivers on a different set of outputs and outcomes.

Don’t be fooled by the similarity in the words project and product, or in the surface-level similarity in how software or digital products are delivered in either mode. The details are key and it’s easy to assume they are similar and end up struggling because you are sitting half-way between projects and products.

In short, there are a lot of changes needed to become an efficient and effective product organization. Understand them and define a clear path to move forward and reap the benefits of a product-focused organization.

Contents

• What is a Product Transformation?
• What is a Project?
• What is a Product?
• What is a Program?
• An Example Assessment
• What Problem(s) are you trying to solve?
• A Framework for Understanding Transformation
• Digital Projects vs. Digital Products (Comparison)
• Summary
• A Little Feedback Please

Companies everywhere are trying to move from project-focused initiatives to product-focused ones. And it’s no surprise why.

In our dynamic world, products and productized services are key to building lasting customer relationships and driving business success.

But, despite the similarity in the words, Project and Product, how they impact companies and how companies are designed, staffed, built and operated are VERY different, and these differences must be clearly understood as executives decide to go through a Product Transformation.

What is a Product Transformation?

A Product Transformation, like any other kind of corporate or organizational transformation, is a shift from one structure or mode of working to another, in order to achieve new or improved outcomes.

In the case of a Product Transformation, the focus is on changing the organization to be more (long term) product-focused vs. (short term) project focused and to reap the business benefits of those products.

Transformations aren’t easy

Transformations can be challenging to undertake successfully.

One of the most common transformations we’ve seen in companies over the last decade is the Agile Transformation. MANY companies went through Agile Transformations (most often via some form of Scrum or SAFe training and implementation) with the hope of better software delivery outcomes.

47% of Agile Transformations Fail to meet objectives.

By some counts, 47% of Agile Transformations fail because they retained “Waterfall leadership”. Now I won’t get into the Agile/Waterfall debate, but the stated reason for failure was the organizations didn’t fully adopt the change to Agile.

Another very popular transformation that you’ve likely heard of is the so-called Digital Transformation. There are varying definitions of the term, but I like this one from IBM.

Digital transformation is a business strategy initiative that incorporates digital technology across all areas of an organization. It evaluates and modernizes an organization’s processes, products, operations and technology stack to enable continual, rapid, customer-driven innovation.

I’ve highlighted a few parts:

• business strategy initiative
• modernizes processes, products, operations, technology stack
• continual, rapid, customer-driven innovation.

Now I won’t dig into all of these too deeply, but the transformation has to be STRATEGIC. i.e. it must be a choice that best helps the organization in achieving goals. It can’t be the whim of a new executive or vanity project or a CYA exercise to cover up other issues.

The transformation modernizes a WIDE-RANGE of areas of the company. It’s not just a local change. It’s a TRANSFORMATION. It’s a SIGNIFICANT change to achieve SIGNIFICANTLY better results.

And it is intended to drive CONTINUAL and rapid CUSTOMER-DRIVEN innovation. Innovation is an often misundstood word. It is often confused with invention. But the two are very different. Invention is something new or novel. Innovation is something new or novel that benefits a market or large customer audience. ie. it has value and market appeal.

I bring this up because these three aspects line up very well with what happens during a Product Transformation. It needs to be STRATEGIC to the organization. It needs to MODERNIZE and IMPROVE how work is done. And it needs to lead to CONTINUOUS and CUSTOMER/MARKET CENTRIC actions by the organization.

When moving from Project to Product, companies need to understand:

• exactly WHERE they are starting from
• WHERE they want to get to,
• WHY they are making this change,
• the BREADTH of changes needed to be successful,
• and NOT HOLD ON TO OLD WAYS of working in Project mode.

What is a Project?

Let’s start with a definition. This is from the Project Management Institute:

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.

And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal.

This is a great definition as it clearly distinguishing projects as temporary (time-bound) and unique in focus with a clear end goal.

What is a Product?

So then what is a Product?

A product is an object or service that addresses a customer or market need that is sold, licensed or made available to customers.

A product may be mass produced and change little over time (e.g. Kellogg’s Corn Flakes, IKEA Billy bookcase), or, particularly in the case of digital products, will change and evolve significantly over time (e.g. Microsoft Office, Salesforce.com’s offerings etc.)

Looking at these two definitions, they are CLEARLY very different.

A project is a one time focussed effort that has a clear beginning and end.

A product is a long-lived object or service that is defined and provided to a market.

The output of a project is a singular result focused on a “singular goal”.

A product is itself an output, has a long lifespan (possibly years or decades) and may see ongoing change and updates over time.

What is a Program?

It’s also important to also discuss Programs. Often the terms “program management” and “project management” are used interchangeably, but Programs are distinct from and more comprehensive than Projects.

A Program can be thought of as a series of projects that are related to an overall organization objective.

The example I use in this article is:

…a project to implement a 3rd party customer service application could be part of a program to address a company’s overall customer satisfaction issues. Other parts of that program might include projects for onboarding and training new customer service representatives, restructuring how that department operates, marketing messages to customers about this new initiative etc.

As you can see, a Program is a larger endeavour that consists of many individual projects. It is larger in scope, in duration and ideally in overall value to the business.

The reason it’s important to also understand Programs is because Projects and Products aren’t the only two modes of operation. Many companies, especially larger enterprises. have both project management and program management teams, and longer term or ongoing efforts often fall under Program Managment.

For example an IT organization in a large enterprise might have some teams who are focussed on implementing and supporting a complex CRM and content management system for their Sales and Marketing organizations. These efforts will likely last for several years, particularly as business goals and company needs change.

The purpose of this article is to focus more on Projects and Products, but acknowledging that Programs exist, and are related to Projects is important.

I will not elaborate too much more on programs, but think of them as an operating model that may get impacted if companies shift from project to product.

Photo by Dmitrii Ko — https://unsplash.com/@goyongsu

What Problem(s) are you trying to solve?

This is a fundamental question that everyone thinking about ANY type of transformation should ask. I will use the word problem, but the driver(s) behind a transformation can be defined via needs, opportunities or literal problems that have been identified.

As mentioned earlier, the reasons for the change should not simply be an executive initiative or corporate vanity. I’ve spoken to a number of people who went through various types of transformations; some successful, but many not. The primary reason for those that failed was that there wasn’t a clear reason for the transformation.

Don’t Do This — Example 1

In one case, a large transportation company hired a new CTO to help them modernize the development practices of the IT organization. And while modernization is a good objective, it is not in itself sufficient to focus specific changes.

What does “modernization” mean for that company? What were they doing that was not “modern” enough? What would be the expected results of a “modernization”?

The new executive came in, moved the company to an “Agile/Product” model, hired Agile coaches, and converted Project Managers into Product Managers (without any real training).

Needless to say, this didn’t go well. The upheaval caused problems with other business units that needed the services and support of the IT organization. Attempts were made to address the problems, including bringing in Product consultants. Some successes emerged, but ultimately the CTO was pushed out.

Don’t Do This — Example 2

Another example involves a well known financial firm. A new CIO came in and mandated that SAFe be implemented. Why? Because they had done it at his previous firm and it was successful? Sure, but what was true at his previous firm was likely not true at the new one.

Long story short, SAFe was implemented, but problems ensued, and then SAFe was unimplemented about 2 years late. IT teams now operate in the modes that best work for them and deliver the results they need. i.e. no cookie-cutter methodology. It works for that company, and that is what is most important.

In both examples above, what problems were being solved? What changes were needed? What outcomes were expected? It’s really important to understand this at the START of any transformation. This usually is done via an assessment. i.e. an investigation into the organization, interviews with key people and teams, hearing first hand what is and isn’t working, and what problems, needs, opportunities exist.

What is visible from the C-suite may not jive with the reality from lower levels, and vice-versa. Getting a consistent, EVIDENCE-BASED assessment of the situation is key. Some things will be working well. Great. Don’t impact those unless absolutely necessary. Some things will need *some* improvement and some things will be broken or need *significant* improvement.

An example assessment

Laying out this entire picture is important so all can see. In a Project-to-Product assessment I did a number of years ago, I found a lot of good, but also some problems.

Here’s a snippet of some of the findings, just to give you a sense of what it looked like in one company.

Positive — Working Well

• Strong culture of open discussion amongst staff
• Consistent views that employees understand annual business goals and how their work contributes to those goals
• Strong alignment and collaboration across members of the Scrum teams

Mixed — Room For Improvement

• Mixed opinions WRT culture, trust, accountability, and conflict resolution across departments
• Mixed views on relationship between business goals and company strategies
• Roadmap is updated periodically but irregularly
• Role clarity and communication across cross-functional teams can be improved

Negative — Significant Improvement Required

• Lack of a coherent and consistent vision for products
• Lack of alignment at Sr. Leadership level on vision and strategy
• Lack of a repeatable roadmap process that produces believable roadmaps
• Lack of communication within company on roadmap changes
• “Roadmap” is project focussed, tied to individual deals and customer commitments

As you can see there is a mix of positive and negative. This was from a company that had tried on their own to move to a Product model. They had people with the title Product Manager, but also had Scrum teams and Product Owners. They were primarily sales-led and that had an impact on how they operated, what product decisions were made etc.

They had done, what I call the easy parts. e.g. hire “product managers”. Change their messaging to emphasize products vs. services.

They wanted to become more product-focused, but it wasn’t a cookie cutter transformation. There were clear problems and we crafted an approach together to move in the right direction. Some of the initiative we completed were:

• Clarified product roles/responsibilities
• Defined and communicated clear company and product visions
• Defined clear business objectives for each product
• Defined a consistent product roadmap process and created clear product strategies and roadmaps
• Implemented an ongoing process of market and customer discovery
• Created an agreed-upon method to address “one-off” sales opportunities

There were other changes made but these were some of the more impactful ones. This took place over a period of time — about 2 years. Now that may seem like a long time, but I have a mantra that I often repeat:

Change is a process, not an event

Organizational change takes time. The company has to continue operating, building, marketing, selling and supporting its products/services. And in the midst of this, the company also has to enact the changes needed to move from a project model — with all it’s inherent assumptions, processes etc. into a product model — with all it’s inherent assumptions, processes etc.

Additionally, this happened during the pandemic when everyone was working remotely, there were people who left the company, new people who joined etc. It was a constant stream of unintended change as well as intended transformational change.

It’s not simple. I sometimes use the analogy of trying to change the oil of a car, while continuing to drive the car. i.e. in business, we can’t put the company up on a hoist, stop everything and make the changes. So those changes must be done over time and integrated into the workflow. And let’s not forget that even without these changes, business can be chaotic due to market forces, competition, regulation, technology and other impacts.

A Framework for Understanding Transformation

Change can be confusing and having a clear way to understand the impacts of that change can make it much easier to comprehend and act upon. I use the following framework of 5 categories to classify impacts of change.

• Operational — processes and activities that are performed
• Organization — structure, roles & responsibilities, skills, of people/teams
• Technical — technologies and tools that are used
• Business — business model, revenue, expenses and strategy
• Cultural — values, beliefs, attitudes of the people in the organization

5 Categories of Transformational Change

Not every transformation will include elements in all 5, but for something as significant as a shift from Project to Product, where most parts of an organization will be impacted, there will be changes across many of them.

In the example I gave above, the changes I listed (as well as those I didn’t) fell primarily into Operational (e.g. the roadmap process), Organizational (e.g. roles/responsibility changes), Business (revenue recognition and accounting practices, product/business strategy) and Cultural (understanding what it means to build support products vs. projects). There weren’t a lot of technology changes as the Engineering team was on top of that on their own.

In future posts I will dig into each of these 5 areas, but in this post, I’ll focus on the high level differences between Projects and Products.

Digital Projects vs. Digital Products

When it comes to digital products, in particular software, there are many differences between the outputs of projects and products.

The following table provides some of the key differences between the two. There are likely several more, but let’s focus on these ones below. .

Table contrasting Project and Product companies

1. Number of Customers

This is the starkest difference between Projects and Products.

Projects

Projects are typically focused on delivering a defined solution to a single customer or small number of customers. I.e. n≃1. i.e. it could be a single external customer or a group of internal customers (e.g. a Marketing team or department etc.)

Products

Commercial products are built for markets that typically contain hundreds, if not thousands (or millions) of potential customers. Building for a market is very different than building for a single customer, and requires a VERY different process to understand needs, interpret, prioritize and deliver them.

Building for a single customer focuses on the specific needs of that customer. Building for a market means understanding common use cases or needs across the market (or market segments) and addressing them in some priority order.

In addition, market needs are dynamic and change based on many factors. This means that it’s critical to have ongoing market and customer intelligence to ensure you continue to meet market needs as they change.

2. Timelines

As mentioned earlier, a project typically has a fixed starting and ending period. It is finite in scope and timeframe. A product is very different. While product development cycles definitely have a starting point, products are ongoing and long lived. E.g. Microsoft Word is almost 40 years old.

Projects

Projects have a project lifecycle with a clear start and end. According to the PMI, there are 5 phases to that lifecycle.

• Initiation — define scope and feasibility
• Planning — create detailed project plan with work, timelines, resources
• Execution — execute on the plan
• Monitoring and Controlling — track progress and make needed adjustments
• Closing — complete deliverables, final signoffs etc.

Products

Products have their own lifecycle, which is very different from a project lifecycle and can run for decades. Within each stage there can be may iterations or release of new product enhancements. i.e. there is ongoing development, not simply at the beginning. The traditionally defined product lifecycle stages are:

• Development — initial development based on market research
• Launch — initial product launch and availability to the market.
• Growth — product growth via customer acquisition in the market
• Maturity — product reaches a mature stage, growth slows and product investment is reduced
• Decline — customers move away onto newer products, revenues decline
• End of Life — ultimately the product is removed from the market.

Many products, like Word mentioned above, have very long lifecycles and can live in Growth, Maturity or even decline for extended periods of time.

3. Objective/Focus

Projects

In Projects, the needs of the specific customer or client or the combined needs of the small number of customers are understood, defined and implemented. Ideally the software produced meets those specific needs.

Products

In contrast, a software Product cannot address the specific needs of dozens, hundreds or thousands of (potential) customers. Instead the overall needs of the market are understood, and common use cases or usage scenarios are defined and implemented. The product supports the (somewhat generalized) needs of the market, not the specific needs of any given customer. Additionally, products (should) have clear business goals (e.g. adoption, retention, revenue, profitability, growth etc.) and companies work to achieve those goals.

4. Funding

Products and projects are funded in very different ways.

Projects

A Project, given specific scope, a start and an end, and clearly defined headcounts, is funded for the duration of the project. i.e. the project team members, and other necessary resources are assembled and funded by the organization to complete the project.

This in itself entails a complete scoping of the project and efforts up front to understand the amount of effort and thus funding that is needed in terms of people (salaries, remuneration), technology, tools, and other expenses.

Products

Products, on the other hand, have a long lifecycle, and thus the team(s) that work on them are employed or contracted with the expectation of a longer term focus on the product.

A small team is often allocated to a given product. E.g. Amazon’s two pizza team rule. The product team is often composed of different people than a project team.

i.e. the lack of an explicit project manager is one common difference and the inclusion of a product manager responsible for driving the success of the product is another.

Additionally, unlike a project which is developed and deployed, a product requires support from the rest of the organization to be successful. E.g. from marketing and sales, customer success and support etc. i.e. the “funding” for a product is much broader than the product team that defines, builds and delivers the product.

5. Business Model

Project

A Project-centric business model is tied to the services delivered in a given project. i.e. revenue is often tied to time and materials for the work to be completed. Revenue can also come from other sources such as customer-specific training as well ongoing operations and support contracts, possibly future customization and technology licensing.

Projects are sold and then built and delivered. i.e. a consulting company markets its services, bids on projects, wins them, builds and delivers. Something like this:

Project: Market-Sell-Define-Implement-Deliver

NOTE: For internal projects — e.g. in a large entrprise like a bank or pharmaceutical company — the Market/Sell portions would be replaced with something like Decide/Fund.

Product

Product-revenue is principally though licensing (one time, subscription, pay-per-use etc.) and services (support, training or other services), though there can be many models, including indirect models such as advertising etc. The primarily point being that in most cases, the revenue model is NOT for services rendered, but for ongoing use or utilization of the product. Product pricing models also scale — # of users, # of queries, amount of CPU, percentage of transactions etc. In the case of commercial products, the process looks something like this.

Product: Define-Implement-Deliver-Market-Sell

Here the process is different than with projects. The product is defined (based on market research etc.), implemented and delivered (release) and then marketed and sold. But there are loops from Sales to Marketing (an ongoing process of marketing and selling, and an ongoing process of defining (based on research), implementing and delivering.

This ongoing process is a clear distinguishing difference between projects (one time) and products (ongoing)

Photo by Ifeoluwa A. on Unsplash

6. Financial Metrics

Projects

The financial metrics for a Project can be complex, covering salaries, travel, materials, hardware, tools etc. depending on the specific requirements of the project. But at the highest level, they are often relatively simple.

i.e. the contract price/value being paid by the client for the project.

This is often based on some form of time/materials or cost-plus calculation. The goal is then to deliver the project under cost in the required time and quality to make a sufficient profit. This is the basic model for a lot of project driven organizations.

Products

Product financial metrics are more complex than project financials given they are tied into the operational costs and revenues of the business and span virtually every org in the company from engineering to marketing to sales to support etc.

The amount of expense may vary over time. The goal of the product is to drive significant revenue and profitability over its lifecycle. This is not a cost-plus or other project-like model.

Pricing models for products can vary from simple to complex and there is a LOT of freedom to structure and update price, packages, bundles etc. to maximize revenue over the product lifecycle.

In general, products can be enormously profitable as their revenue models are often scalable (e.g. usage-based or seat-based) and ongoing (e.g. subscription). The LTV — Lifetime Customer Value — is a common measure of product financial performance.

7. Revenue Source

Related to Financial Metrics is the idea of Revenue Source. i.e. what are the revenue streams for each?

Projects

In general, Project revenue is tied to labour and deliverables. i.e. the work done by the people (and their tools) to deliver the output of the project. The bigger the project or the more projects completed, the more revenue. This can be incredibly profitable if there is significant margin on the labour, or if the perceived value of the deliverable is large. e.g. a company may pay a significant premium for a custom, critical business application.

Products

Product revenue typically comes from licenses or subscriptions sold to customers/users. Those could be per-seat or per use or based on some other value metric. But in products, there can be multiple revenue streams from different sources such as advertising and sponsorships, sales of data, user fees etc. In addition, revenue can be ongoing based on subscription or usage models.

This distinction between Project and Product revenue requires a wholly different business and operation model, that must change if a company is moving from Project to Product focused.

Photo by Marc-Olivier Jodoin on Unsplash

8. Architecture and Design

Software architecture defines the fundamental underpinning and structures of a software application or product. Architecture often defines how performant, scalable, flexible, secure and resilient software applications are.

If the needs of the software grow beyond what the architecture allows, then the architecture can be updated. The design of the software, from connectivity, APIs and other interfaces can define how people and systems can interact with the application. Both architecture and design are key to creating usable software applications.

Projects

For Projects, the architecture and design are focussed primarily on the requirements defined for the project.

i.e. there’s no need to build a scalable architecture or flexible interfaces if the requirements don’t specify that. Often with projects, architecture and technical debt are ignored for the sake of expediency in delivery. It’s been my experience that companies — particularly those building internal applications — don’t focus enough on ensuring the architecture and design are updated in a timely manner. This often hampers implementing new features as no one wants to pay for that architecture rework.

Products

In software Products, the architecture and design must incorporate forward thinking. I.e. architecture and design decisions should be made with the clear understanding that they may change in the future and the work done should not hinder future changes.

This doesn’t mean designing and implementing for an unknown future, but thought and effort is put in to make those changes easier. E.g. defining APIs or user interfaces that are easily leveraged or modified when needed can be incredibly beneficial, vs. a rip and replace mindset.

9. Risk Management

All software development involves managing risk of some kind.

Projects

For Projects, the focus is to minimize risk and deliver the project on time, on budget with required functionality and quality. In projects, risk is managed and ideally minimized because project success and profitability are tied to successful project completion.

Products

When building Products, risk is ever present in all aspects of the product development lifecycle. Products are core to business success and there is always risk in any business venture. The key is to focus on accepting a certain amount of risk in order to gain certain benefits. I.e. no risk, no reward as the saying goes.

Thus unlike in projects, risk is not to be minimized for products. I.e. a startup or new product is an incredibly risky undertaking and product development and go-to-market are full of unknowns and uncertainty.

VCs expect a certain percentage of their portfolio companies to fail. In larger companies, not all products or strategies succeed. In fact, if a company has a VERY low level of failure, it may not be taking enough risks.

The contrast between projects and products when it comes to risk management couldn’t be starker.

Photo by Stephen Phillips - Hostreviews.co.uk on Unsplash

10. Marketing/Sales

Marketing and Sales objectives and processes are very different in project environments vs. product environments.

Projects

In Project-oriented companies, Sales is focused on solution or consultative selling processes, trying to identify specific customer needs and budgets and then crafting a proposal and solution for those needs.

The client is looking for something specific to be built for them, not something generic that can be bought and used in short order. Sales is constrained by the ability for the company to implement the contracts they bring in, but a very large custom contract is seen as a big win for a project company IF they have or can acquire the resource to deliver the project.

NOTE: For convenience, I’ll repeat the image shown earlier in this post for Projects.

Project: Market-Sell-Define-Implement-Deliver

Products

In Product companies, Sales sells the product(s) that exist or possibly the versions of the products that will soon exist, based on defined company plans to enhance the product.

Product companies identify prospects that need what the products can address, vs. addressing what the prospects need (projects).

Likewise Marketing a Project-focused company means marketing the company’s ability to build the applications the company has the expertise to build.

e.g. some software development agencies focus on verticals like ecommerce or financial or mobile or machine learning applications etc. Marketing that expertise to the target markets potentially looking for custom applications is very different from product companies.

A product company may have ecommerce, or financial or mobile or machine learning expertise, but that expertise is focused on marketing the the products they’ve built for those domains.

NOTE: For convenience, I’ll repeat the image shown earlier in this post for Products.

11. Delivery

Delivery can be defined as providing the final deliverable to the intended recipient.

Project

For Projects, that final deliverable — a software application in this context — is made available to the customer or customers requesting it. There may be some post-delivery requirements tied to training, enablement or operations, but most projects are focused on that single deliverable.

Product

In Product, there is no “final” deliverable, but instead there is an ongoing process of new product capabilities, bug fixes, maintenance work etc. moving into production and being made available to the customer base, in line with individual customers’ license agreements and access rights.

Executing on this ongoing process needs to be built into the DNA of the company in terms of processes, skills, collaboration and more.

Photo by Igal Ness on Unsplash

12. Incentive Models

This is not an obvious difference, but if you think about how a Project company must operate vs. a Product company, incentive models will be significantly different, especially for sales.

Projects

The goal of a Project company is to win contracts that involve customized work for each client. The larger the deal, the more customized work required. Each contract is different from the other, though there may be some common elements across them IF the company focuses on a specific domain or certain type of digital product.

But when it comes to Sales compensation (as one type of incentive model), the larger the deal the better, for both the sales rep (commission etc.) and the company, as the company is structured to handle the large inflow of new custom work.

Products

What works for a compensation model in a Project company is the EXACT thing you want to avoid in a Product company. i.e. you don’t want a LOT of bespoke (custom) work with every deal. Product revenue models work best when the product — without significant customizations — is marketed and sold to customers.

As Rich Mironov states:

All profits are in the nth copy (or nth user)

Sales reps who sell the product along with heavy customization work are thinking about their commission cheques, and not company profits. A company moving from Project->Product must change the incentive and compensation models to align with that. In fact, in some cases, the companies may have to change parts of the sales teams because selling large custom development contracts requires a different skillset and org structure than selling multiple software license deals.

And incentive changes don’t stop at Sales. How marketing teams and engineering teams are incented has to change. For example, in projects, keeping costs down and finishing “on time” is critical for Engineering teams. They may be bonused on meeting delivery dates or cost limits. With products, what’s really important is ongoing delivery of high-quality software that meets market needs. Costs aren’t as important if the Engineering team has the ability to execute in reasonable timeframes.

Summary

The previous sections outline some of the ways that projects and products are different. It’s unfortunate that the words project and product are similar and *some* of the underlying concepts are analogous, but overall the two are very different in many ways.

For a software company focused on building scalable products that can be sold/licensed to large numbers of customers with little modification, being product-focused requires a very different set of objectives, decisions, organizational structures, processes, mindsets and culture than a project-focused organization.

Sometimes companies mix the two together, with projects and products. While this may be necessary in some cases, the differences between projects and products, financially, operationally, organizationally etc. make the situation far from ideal. The company can’t optimize on one or the other, but lives in a weakened state, trying to do both, and often neither very well.

A Little Feedback Please

If you’ve read this far, thank you. I’d like some feedback on the article to make it better. It should take just 1 minute, but will really be valuable to me. Thanks in advance.

===> Click Here <===