Focus on Products Instead of Projects to Build a Stronger Company

Gone are the days when a project team could deliver something on time and budget and call it a success. A company can spend a year developing a product, meet all of the project requirements, and still fail to achieve the desired business outcome. These failures can result because the project success parameters and the business outcome goals were not aligned. Further, the project may have gotten tunnel vision: pursuing deliverables that were later revealed to be non-optimal compared to what could have been.

Tunnel vision is a natural consequence of the product mentality. Projects tend to lock money and talent into set positions for months at a time, with little room for changes. Instead, businesses should always strive to achieve an outcome, such as a positive response towards their product post-release. This can be a moving target, so requirements and goals may change mid-development.

In the past, major changes mid-project could seriously derail chances of success. But product development is no longer on-rails. Instead, it’s done through agile cycles, allowing businesses to develop a working prototype, make improvements, and set a course towards realizing the fully-functioning product over time. 

This is the major difference between supporting a product versus aiming to succeed in projects. Projects have a set destination, and they end. Product support, on the other hand, is ongoing, and it constantly demands work and strategic planning.

Choosing to focus on products instead of projects positively affects organizational planning cycles, processes, and even team structures. The nature of the work itself also changes. It spreads responsibilities across the organization because every team has the same goal: providing tangible value to customers and the business.

Critical Differences in Product Focus vs. Project Focus

A project mentality sets an outcome in stone, one that may not be achieved until months (sometimes even years) later. Once this outcome is achieved, but changes are needed, another project round must be planned in order to allocate resources. This structure generates tremendous inertia, which means the project will have a hard time changing course once it’s begun.

A product mentality, on the other hand, provides ongoing resources towards maintaining the value of the product. The business commits to supporting the product and making needed changes, both during and after initial development. Once the product is released, it still has resources dedicated to its maintenance. What’s more, the product teams have permission to adjust the course on product planning and strategy in order to reflect the current ideal.

Further, the project’s value is determined before any work is done, and its success is determined by whether it is completed on time and within budget. Metrics capable of measuring the project’s true value to stakeholders may be left out of the equation. For example, a project intended to revise a piece of popular software with a wide install base could plan for features to be added over six months. These features may have been selected based on market research from whenever the project was initially planned. But things change, and new information comes to light. It may be possible that new features or consumer demands may be trending, making the new version of the popular software obsolete before it even launches.

What’s missing is two-fold: flexibility and timely information. Both come from a product development process that delivers frequent changes, measures the success of those changes, aggregates this data with current market research, and then uses all of this to inform the next planning cycle. Projects can work like this, but they do so in slow-mo. 
What’s worse: those assigned to a project may be reassigned once the project is completed. Without a dedicated product team or product owners, responsibilities can be juggled in a way that splits attention too finely. 

Capital resources may be allocated the same way. Without ongoing funding and tools dedicated to supporting a product, operations teams may be left with little to nothing to ensure that consumers are continually satisfied. A backlog of problems and feature requests can grow, and these issues may only be addressed once a new project timeline is set and funded.

Product Focus Bakes In Value at Every Step

A product-focused team continues to serve the product until the end of its lifecycle. Often, multi-disciplinary teams are assembled so that all competencies needed to support the product are at hand.

Such a team structure introduces accountability and thoughtfulness at every stage. It also allows changes in scope, budget, and schedule when needed, since team members aren’t locked into one purpose or one limited set of project goals. Instead, people can change the product goals based on real-time conditions and efforts. So, if a performance test indicates a problem, the team can change the requirements on the spot. If a global pandemic breaks out and setting up online collaboration apps will delay the delivery date, for example, the timeline can be altered with minimal disruption.

Product-focused work uses agile’s dynamic and iterative work cycles, which help teams deliver value more easily. Plus, it’s the “right” value that customers and the business are looking for, based on key metrics introduced earlier in the process and monitored at all stages of development and delivery. Teams can pivot quickly, reduce their overall cycle time, and validate the product against real-world benefits. Because of this adaptability, teams are able to deliver product changes more efficiently and ensure that these continual updates can provide real-world value. For future products, these teams will be able to evaluate product requirements and schedules more accurately, leading to products that deliver more features in less time. 

How Does Having a Product Focus Change a Company?

Organizations interested in shifting from a project focus to a product focus can take the following steps to make the transition successful:

• Move away from only funding teams and projects for a single purpose. Instead, form teams capable of contributing to all aspects of product quality. No area of the product will be unaccounted for, which would otherwise result in delays or quality compromises.
• Give teams the freedom to change their budget, scope, and timelines at any time without penalty. 
• Ensure all teams work towards the same overall business goal(s).
• Communicate changes in goals across the organization so everyone can adjust.
• Determine the value metrics to track at every stage of work and provide teams with real-time feedback so they can pivot or change as needed. 
  • Explain how these metrics are affected by their work, so people invest in the right tasks and feel invested in their work. Often, IT teams don’t know or understand how their work affects the business. 
  • IT operations and service teams can help provide visibility into the status of key metrics, helping the entire organization stay aligned to their common business goals.
• Tie success parameters to value creation and not just meeting a target date or budget. 
• Ensure work priorities reflect the current state of the industry, consumer market, etc., and not the state when the ideas were first proposed. As many have seen this year, the world can change quickly, and what a company decided to build several months ago may not match what the market needs today. 

Finally, having a product focus means the product team has ownership over product success even after it is released to production. Teams must monitor, maintain, and continually improve products based on observed metrics to ensure they will continue to deliver value. 

IT Can Provide Leadership During a Product-Focused Transition

Making the switch from project to product focus isn’t a matter of throwing out the traditional IT project management book. IT teams must lead the transition thoughtfully within the organization. 

Data and analytics can fuel the changes and provide feedback to business leaders as they make decisions. Root cause analysis, for example, can pinpoint the source of coding defects that lead to business disruptions and customer dissatisfaction. Resolving the root cause of persistent problems through subsequent changes concretely produces more value to end-users. Additionally, tracking relevant value helps the product team — and the organization supporting them — understand what’s at stake for their work. Everyone is encouraged and expected to contribute to the product to get it across the current finish line. And once that finish line is crossed, the teams can get ready for another cycle.

This process of using data and analytics to identify areas for improvement is the value stream management approach. It helps IT leaders identify and develop appropriate metrics to uncover where value is created or lost and make improvements. Unlike on-project teams, product teams are accountable for results post-delivery. They can know the level of business value they’re delivering, and they can respond to it when planning the next iterative phase.

Remember, the world is always changing and your product must change just as fast to keep up.