Context Assessment

How to approach your product based on complexity and uncertainty

Is your product a sheepdog, cow, colt, or bull? Use this assessment to gauge the complexity and uncertainty involved in your product and find out how to treat it accordingly.

First Name

Email Address

What product are you assessing?

Tell us the name of the internal product you'd like to evaluate using the Context Leadership Model.

Complexity

The nature of your product and product team determines its complexity, which affects the ease or difﬁculty the team has working on the product. Higher complexity implies the need for more structured communication and documentation. In contrast, lower-complexity products can often thrive on informal communication channels.

Team Size

Small - about 2 people
Mid-sized - about 15 people
Large - about 100 people

A large team generally makes for a more complex product. The number of potential communication paths grows fast as more people join, even when parts of the work are decoupled. If a team must be large, it's worth subdividing it at loosely coupled interfaces so subteams can act efficiently.

Mission / Safety Criticality

Speculative
Established market
Safety-critical or significant monetary exposure

If the product puts lives or business-critical functions at risk, it has to be treated differently than one where the only cost of failure is the investment in the product itself. Higher criticality means greater visibility and exposure for the organization, which requires more well-defined tracking and risk management — adding to complexity.

Team Location

Same room
Within the same building
Multisite, worldwide

Having everyone in the same room enables high-bandwidth communication across the product team. A widely distributed team — or one with a significant portion several time zones apart — can significantly increase complexity. This can be a hard attribute to judge; use your own judgment for a team with just one or a few dispersed members.

Team Maturity

Established team of experts
Mixed team of experts and novices
New team of mostly novices

An established team of experts who've worked together for years can almost anticipate what teammates need. A brand-new team of relative novices requires far more hand-holding, usually in the form of more formalized documentation of requirements and specifications.

Domain Knowledge Gaps

Developers know the domain as well as expert users
Developers require some domain assistance
Developers have no idea about the domain

Many products involve business processes that everyone on the team needs to understand at some level. At minimum, the team needs full-time access to domain specialists to resolve ambiguities. This is simplest when developers are domain specialists themselves, and becomes far more complex when access to domain knowledge is limited.

Dependencies

No dependencies
Some dependencies
Tight integration with several other products

The more a product depends on other products or third parties, the more complex it becomes. It's critical to manage those dependencies and track others' activity to stay aligned — though an established third-party dependency may not add much complexity if the team has a track record of stable interfaces.

Uncertainty

The needs of your customers and the choice of technology are the two major drivers of uncertainty for a product. Higher uncertainty implies the need for a means of absorbing changes and adapting to those changes, with the idea of getting to the ideal solution, though it may not necessarily be the solution that was envisioned when you started work on your product.

Market Uncertainty

Known deliverable, possibly a defined contractual obligation
Initial guess of the market target is likely to require steering
New market that is unknown and untested

If the market or customer needs are well understood, the product probably won't need much steering. If they aren't well understood and can only be discovered while building the solution, the ability to steer toward the discovered goal — rather than the one initially stated — becomes critical.

Technical Uncertainty

Enhancements to existing architecture
We're not quite sure if we know how to build it
New technology, new architecture; some research may be required

Mature products built on proven technology don't involve much technical uncertainty. Sometimes a product experiences uncertainty while rolling out technology that's proven elsewhere but new to the team. Products built on the latest technology carry a high degree of technical uncertainty.

Number of Customers

Internal customer, or one well-defined customer
Multiple internal, or a small number of defined, customers
Shrink-wrapped software / open market

One major amplifier of market uncertainty is the number of customers. A product with a single internal customer is quite different from one with multiple customers and multiple voices, which creates the potential for conflicting needs. Many markets are fickle and fraught with uncertainty.

Safety Market Domain

Duration

0–3 months
3–12 months
More than 12 months

The further out the future is, the greater the chance for technical or market uncertainty to affect it. Iterative and incremental delivery can play a big role in minimizing the risk of uncertainty in products with a long duration.

Approach to Change

Significant control over change
Moderate control over change
Embrace or create change

How a team approaches managing change shows how much flexibility it has for managing uncertainty. Some components may be used by other products, which can limit how much steering those dependent products can tolerate — so continually modifying interfaces may not be acceptable even when uncertainty suggests a need to absorb change.