Software projects are a popular way of funding and organizing software development. Projects are funded on a case-by-case basis on the basis of benefits projected in a business case. They are organized in the form of one or more temporary teams whose members have durable reporting lines outside the project organization. They are staffed from a “pool of talent” whose members are considered fungible within lines of specialization. And usually, a software project team’s job is to build or enhance some system or application and move on.

However, projects are not the only way of funding and organizing software development. For instance, many companies that sell software as a product or a service do not fund or organize their core product/platform development in the form of projects. Instead, they run product development and support using near-permanent teams for as long as the product is sold in the market. The budget may vary year on year but it is generally sufficient to fund a durable, core development organization continuously for the life of the product. Teams are funded to work on a particular business problem or offering over a period of time; with the nature work being defined by a business problem to address rather than a set of functions to deliver. We call this way of working as “product-mode” and assert that it is not necessary to be building a software product in order to fund and organize software development like this.

In product-mode, it is not just the team that is long-lived, its association with a problem area is also long-lived. Product-mode teams often run in pull-based development mode with a focus on achieving flow and less emphasis on achieving predictability using story level estimation and release plans.

An ideal product-mode team is an empowered, outcome-oriented, business-capability aligned , long-lived, cross-functional, ideate-build-run team that is able to and expected to solve problems and improve business outcomes, rather than deliver scope on schedule. The problems that these teams take up are usually long-lived e.g. continuously improve the conversion from cart to checkout (reduce cart abandonment rate). Problems also need to be defined sufficiently narrowly so that individual teams can own them. For instance, although “Net Promoter Score” (NPS) is a great holistic metric, it is typically too broad for any particular team to sign up for.

There are several, less-than-ideal variations of teams operating in product-mode. Some places use a halfway approach of project-mode funding and product-mode organization. Even the product-mode organization is not always build+run. Or the cross-functional teams consist of people reporting to different function heads.

Product-mode is no longer limited to companies that sell software. It is common among so-called tech businesses enabled by tech platforms that stream content, e-tail, distribute mutual funds, find cabs, accommodation, flights, you name it. It is also catching on in the digital/product/engineering/IT departments at more traditional, old-guard businesses. For instance, Insurance Australia Group (IAG) recently moved away from projects to a more durable platform organization operating in product-mode. ANZ Bank is trying something similar.

Products-mode works best when teams are organized to be simultaneously aligned with business relevant capabilities and with enterprise architecture boundaries. Without the former, they may lose alignment with business goals. Without the latter, they lose out on autonomy i.e. the ability to evolve their systems relatively independent of other teams.

Improvement of a metric directly related to a business outcome or not more than one or two levels removed from a business outcome. Thus, every product-mode team is ideally a business KPI driven team. For example, Scout24 operates like this with teams responsible for traffic, engagement etc.

There is relatively less emphasis on assessing projected benefits upfront, especially amongst the best such teams that execute with short cycle times and can therefore try new ideas without incurring a high cost of failure. The product owner is empowered to approve development of roadmap items as they see fit. By developing in small, end-to-end iterations, product owners are able to detect early any efforts that miss the mark and thereby fail-fast (fail-cheap).

Product owners prove actual benefits either with data from A/B testing, analytics, user surveys, etc. or with feedback from business. This ability is dependent on good engineering capability to develop and release frequently in small chunks and good analytics capability to determine delta changes in adoption, conversion etc.

There is emphasis on formal assessment of projected benefits prior to project approval. There is typically no mechanism for validation of actual benefits after project delivery.

Roadmap items are prioritized by product owners and their business counterparts. Cross-cutting initiatives are prioritized by the business or tech leadership. Initiatives don’t get their own team. They are parceled out to pre-existing product-mode teams.

Not by design. For any given individual, the next project may be in a completely different area.

A product-mode team is funded on a rolling basis (e.g. for a year at a time) with periodic reviews. The team takes on one problem after another, roughly the same space, working through an evolving roadmap aligned with product/business strategy.

“Product-mode” is a way of working. It is a way of funding and organizing software development that differs significantly from the projects way of doing it. Although generally applicable to digital-age enterprise IT, this way of working is especially suited to those who aim to drive business through a digital platform. The differences with projects are summarized below and elaborated in the rest of the article.

Benefits of Operating in Product-Mode

In today’s (2017) business environment, operating in product-mode has several advantages to operating in projects-mode.

Ability to Reorient Quickly It used to be sufficient for IT/engineering to be setup to respond within a year of receipt of market intelligence or feedback. With “digital” going mainstream, such is no longer the case. Let’s take an online retail example. Broadly, the capabilities of a basic, online retail platform may be classified as catalog, order management, payment and fulfillment. In projects-mode, it might be the case at a point in time, that owing to priorities, we have active projects affecting order management, payment and fulfillment but not catalog. Now if were to receive unexpected, catalog related feedback from the market or from business stakeholders, we wouldn’t have a team in place ready to act on the feedback. Usually, any new feedback would by default be subject to business case and project approval processes followed by prioritization for staffing. Even if we could suspend one of the active projects and redeploy the team to catalog, the team would likely be new to catalog and therefore unable to hit the ground running. By contrast, in product-mode, we’d have a long-lived team (or teams) dedicated to each of catalog, order management etc. and always ready to act on new feedback. It would only require the decision of the team’s product owner and their business counterpart to divert some team capacity to act on new information. This ability to quickly reorient a ready team is the first component of better responsiveness. Don’t run it like a city Projects-mode is similar to how cities are run. A city has to keep the lights on, so to say, in various departments such as water supply, sanitation, transportation, law and order etc. The people that work in these departments are the equivalent of our ops (run) teams. On the other hand, when new water or sewage treatment plant is to be built or a new metro line is to be introduced, the city funds them as projects and contractors execute them. They are the equivalent of build (change) teams. In contrast to the “We build it, we run it” ethos of modern software teams, a city’s approach is “You build it, we run it” and it works for a city although its citizens might prefer quicker improvement in various areas. On the other hand, unlike the case of software, the skills required for building/changing a city’s infrastructure and services are vastly different from the skills for running them. It might not be cost-effective for a city to pay for always-on change teams. The projects model is cost-effective for cities, but they do pay the price for sluggish performance when they lose out on business investment to other cities. Traditional enterprise IT has followed the two-pronged city model of permanent “run” teams and on-demand “change teams” i.e. the “projects” approach, and have paid the price in terms of responsiveness to the business. Digital-age business can ill afford to be sluggish in responding to feedback from business stakeholders or the market. Business-capability aligned teams need to have the level of funding, staffing and authority to switch focus or pivot their approach to a problem on the fly.

Reduced End-to-End Cycle Time Cycle time is a common measure of responsiveness. Included inside overall cycle time is the time to reorient and the time to execute. Let’s examine the latter component now. Most enterprise DevOps initiatives don’t alter the separation between the “change” and “run” organizations at all. Usually, both organizations adopt some new tooling, some deployment and infrastructure automation, perhaps with some “cloud” thrown in for good measure. They may even realize benefits such as more frequent, automated and reliable deployments. However, due to persistence of the handoff from dev to centralized ops, the end-to-end cycle time of delivering a change doesn’t change much. Product-mode teams don’t suffer this handoff when they deploy and run what they build. They can therefore achieve the full potential of DevOps adoption. Colocation of application level ops with dev also promotes better end-to-end iteration and better understanding between developers and site reliability engineers. Note that product-mode teams usually continue to rely on other specialist ops teams that provide a self-service build & deployment infrastructure, manage data centers and/or take care of non-application level security. These teams may also be run in product-mode even though they are not business capability aligned.

Ability to Truly Iterate COOs often complain about the cost of the tech organization. Yet, they miss one of the biggest opportunities to save money because its root cause is outside tech. Big ticket projects are conceived and funded at one go without an effective mechanism for validating actual benefits. These projects regularly miss the mark in terms of delivering benefits. If organizations had the habit of tracking their benefits realization ratio (actual benefits/projected benefits), they'd be shocked in most cases. A truly iterative development process would be able to fail cheap and save money. Although the notion of iterative development has been around for a while, in practice, iteration only goes as far as a sprint showcase in most cases. Most Scrum teams are bound to scope-based sprint commitments and are expected to deliver scope on plan rather than solve problems. In order to solve a problem iteratively, teams need to be able to respond to feedback (usage analytics, user surveys, stakeholder testimony) of earlier versions of the solution. Product-mode teams, being stable and long-lived can choose to solve a problem in a truly iterative manner. Project teams can’t easily move out of scope-delivery for two reasons. First, they are usually only meant to “build” the solution, not run it. So, they build a version of the solution over one or more releases, hand it over to a team in the “run” organization and move on to the next project. Second, the way project funding works, funds are made available to sustain a team for a duration of time much shorter than the lifespan of the underlying problem being addressed.

Example: A retirement calculator For example, in a financial services company, a project was approved to develop a retirement calculator that would nudge prospective customers into buying retirement products or improving contributions in existing plans. The project team was funded only for the time it would take to build the calculator, not address the underlying problem, which was to improve the uptake of retirement products. Another team would embed the calculator on the company website and a third team would set up the necessary digital campaign to drive traffic to the calculator. At least three different managers (supervisors) would closely track the completion of work with a business stakeholder operating at arm’s length after having specified what to build or at best, having participated in a day-long inception/hothouse. If the delivered solution missed its mark in the market, it would have to wait for another round of funding and staffing to find its way into an improved solution. Adapting it to Product-Mode How would a product-mode org cater to the situation above? Firstly, we wouldn’t think of spinning up a new team to develop the calculator. Instead, it would be taken up by a pre-existing, stable, long-lived team closest to the problem area (i.e. product-mode team). What product-mode teams are we likely to have in this case? Given that this line of business sells a bunch of retirement products, could we have one product-mode team per retirement product? Unfortunately, it is not realistic to have a team per retirement product even if they make sense from a customer perspective because of the commonalities in business process & logic, and the shape of existing systems. On the other hand, a single product-mode team for all retirement products would be too big and unmanageable. Instead, we'd have several business-capability aligned, product-mode teams. Here’s one way of partitioning the long-term customer journey with respect to retirement products: on-board companies, enrol employees, save for retirement, withdraw etc. Note that each partition is customer-centric and is a meaty slice with data and business logic distributed across multiple systems. The whole customer journey is too big to be owned by a single team. A product-mode team therefore exists for each partition (business capability). This is somewhat analogous to the earlier online retail platform example where the overall customer journey is partitioned as catalog, order management, payment and fulfillment. Now, any work on retirement calculators, being an attempt to improve enrolment or savings, would fall into the remit of the enrol or save team. This team, by the very nature of problems it generally addresses, would typically have digital marketing skills and access to marketing systems and assets within the team. The team would now have the responsibility to deliver and prove an improvement in conversion that is attributable to the calculator. As a long-lived team, it would have enough time to iteratively develop and test the effectiveness of the solution whilst attending to other roadmap items during lulls. In terms of cost and time per percent increase in conversion, a product-mode setup would, in all likelihood, compare favorably to a project-mode setup. The only way to verify this reliably for any given organization is to try product-mode for a couple of problems and assess the results.

Knowledge Retention The truth about software is that no amount of documentation, handover, and knowledge transfer can make up for a 100% churn in team. Yet this is exactly what a project model brings about. Tech capability does not reside in maturity models, process templates, documentation, code, or the infrastructure. It resides and grows in a team. Knowledge grows and stays better within stable, long-lived teams that work in the same general area for several years. This contrasts with project teams that ramp up and down every few months. Unmaintainable code results—at least partly—from unmaintained teams. Although documentation is useful and necessary, in organizations that prefer “working software over comprehensive documentation”, it is no substitute for the sort of knowledge retention that occurs within product-mode teams. Product-mode teams allow team members to focus on a given area (business-aligned capability) for much longer than a typical project duration. This helps build knowledge, improves understanding of problems and trade-offs, and enriches the quality of interaction with business SMEs and stakeholders. Do product-mode teams lose knowledge when a team member leaves? Not if they work based on collective ownership of overall scope. Knowledge retention is at risk when team members individually own different features or sub-areas.

Architectural Integrity The incentives involved in project-mode put pressure on teams to neglect medium-term architectural integrity in favor of (often perceived) short term feature delivery. Since the team doesn't face the consequences of that trade off, they don't benefit from the feedback loop that appears when there is longer term ownership. Project teams are known to contribute (inadvertently) to architectural debt by being unaware of enterprise architecture guidelines or simply ignoring them in the narrow pursuit of timely project delivery. In the medium-term, this phenomenon compromises stability of systems and degrades speed of delivery. A couple of examples: They may end up performing a low effort integration with a system meant to be sunsetted instead of taking on a higher effort integrating with an upcoming successor. This compromises the sunsetting roadmap and increases the cost of maintaining an application landscape with multiple systems that do similar things.

They may end up performing direct database integration with a downstream system instead of integrating after exposing its capabilities via API. In turn, this hurts any evolution of the downstream system that requires a breaking change to its database schema. Product-mode teams, on the other hand, don’t let other teams integrate inappropriately with the systems they own as they are more keenly aware of the consequences. That’s the advantage of having “build+run” teams own systems as opposed to projects-mode where run-only teams own them.

Ownership of Code and Systems Team level ownership of code and systems greatly helps a team’s ability to operate in ideate-build-run mode. Ownership allows a team evolve systems faster and in a more controlled manner. But what about the ideal of collective ownership? It is great to aim for collective ownership within teams since the alternative of individual ownership is problematic. Between teams though, a clear demarcation of ownership allows for accountable autonomy. An internal open source model is used at some of the most advanced tech companies. Anyone in any team can propose changes to almost any area of code by sending a pull request to the custodian (similar to core committer team in open source projects) team. Although this model can co-exist with team level ownership, it tends to create a default expectation that dependent teams will self-service the changes they need. It is a common expectation in open source projects (“Found a bug? Great. Please submit a fix.”) but unrealistic at most mainstream enterprise Digital/Engineering/IT departments. For one, there is seldom the level of domain knowledge to effectively make changes to disparate systems. Besides, it requires all code to be maintained at a self-serviceable level of documentation, build (as in, simply checkout and build) and test readiness—a high bar for most organizations. It is one reason why internal open source initiatives have failed to take off in most mainstream enterprises that have tried it. For such organizations, it is pragmatic to keep the default expectation not as one of self-service but rather that of a negotiated dependency. Any change must by default, be agreed with and prioritized and delivered by the owning team.

Team Motivation and Dynamics Teams take time to work together effectively as a unit. Tuckman’s theory of group development asserts that a team goes through a series of suboptimal phases (forming, storming, and norming) before it finds its groove in the performing phase. A project model of staffing runs the risk of disbanding teams just as they enter the norming or performing phase. Product-mode teams, being stable and long-lived can benefit from a long performing phase. Studies have identified autonomy, mastery, purpose and belongingness as key intrinsic motivators. Product-mode teams tend to have greater autonomy and purpose than typical, scope-delivery project teams. Therefore, the introduction of product-mode teams is usually welcomed by the troops even as management takes its time to adjust to a new normal.