The most important factor to deliver value is to understand deeply the user needs and context. That will support the team in delivering just what the customer needs, not filling the products with pottentially undeeded features.

Having more talented developers, incresing the budget and making the team more efficient, are overally good to produce value for the product, but they don’t have such a direct relationship to the value creation that deeply understand the user needs.

While some organizations, e.g. those using the Objective and Key Results (OKR) technique use the year and quarter cadences to set goals, that is just a concrete approach tied to budgeting and governance.

Goal setting can take different approaches (e.g. periodical, milestone or outcome-oriented) depending on the product context.

EBM defines three levels of goals: Strategic, intermediate and tactical. Those levels are designed to give structure to the empiricism in tackling the complexity and maximizing value.

EBM goals can be aligned with other approaches such as Scrum Goals (Product and Sprint) or with Key Results (in the OKR framework). The Release Goal is not part of Scrum, but can be also aligned with the Product Goal.

When the product features show a low usage index, is a clear that the current value (CV) is low. Users are not getting a lot of value out of the product.

Ability to innovate is also impacted, because the maintenance of those features will keep the team away of working on other value-adding features.

A low usage index may also show opportunities for improvement (UV) but at this point of time the priority should be restoring a sufficient current value.

The Time to market KVA is not impacted by this finding.

The empirical mindset pushes us to recognize everything we don’t know and to try small amounts of work to test things before investing a big effort. Those uknowns are typically about the customer reaction, and before trying things, it is effective to try to predict what the experiment will confirm or reject. If the experiment result is succeessful, we can carry on with the investment, else we need to research more.

Releasing features with a significant effort may an highly unefficient way of learning and testing hyphoteses. Checking metrics of things already delivered is monitoring, not experimenting.

Higher management set the organizational strategy and business goals. If the organization is really agile, the teams have a say on how to meet that goals with the products they work on. So that, the Intermediate and Tactical goals should be defined by them, while also being aligned and agreed with management.

Management could give directions, but ultimately the Scrum Teams should be accountable on defining the Product and Sprint Goals.

Finally, while staffing is related to the team needs and the goals they chase, it is not the only factor to staff the teams, and the staffing should not fluctuate directly with the goals to establish some stability in the teams.

The goal of a Scrum Team is to solve complex problems for customers in a way that is aligned with their organization’s mission and goals. Having satisfied customers is a clear indicator that they are meeting their needs.

Having a good productivity, efficiency and high morale are also good indicators of team performance, but those can also exist in situations where the product is not fulfilling the needs of the customer.

When development organizations do not have a clue about the customers, we need some evidence to sustain the decisions. Doing a short user research (UX) activity, such as interviews, may be a cheap and quick way of obtaining that evidence.

Building the whole feature and getting data is certainly an empirical approach to sustain the decisions, yet an expensive one.

Liberating Structures provide a set of facilitating techniques that help to achieve creative solutions and avoid discusion deadlocks. However, they won’t provide any hard evidence to sustain the strategical decisions.

Working on your own and ignoring the stakeholders may not be a good way of building a trust relationship with them for the future.

Software development is expensive. A single Sprin costs many thousand euros. Before continuing to pottentially waste a ton of money based on the team gut feeling, it makes sense to gather some evidence, even if a little delay happens.

Keep on investing without any evidence just because «a lot of money has been spent» is an example of the sunk-cost fallacy. If those features are a failure, even more money will be wasted.

The other options, whether a triage meeting with the Scrum Team or with stakeholders, will keep the evidence constrained to the minds of the people working in the organization.

Both EBM and Scrum help teams and organizations to navigate through uncertainty. Within uncertainty the reality unfolds frequently in unexpected ways. A goal that may seem doable at one point, might render impossible to reach or not worth the effort when we learn more about the reality. So that, all the goals in EBM can change when we have evidences that help us to decide to reach another goal.

Sticking to a goal when we know it’s unreacheable just because we do not want to upset the management is not going to help neither the team nor the organization. Persisting on reaching a goal when we have enough information to abandon it, may be probably a waste of time.

Splitting organizational goals into groups is one way of creating alignment, though not the only one.

Teams can also get inspired by the organizational goals and define their own goals which make more sense to their context. Sometimes, breaking organizational goals and trying to match with team goals becomes quite artificial.

In other to speed up the value creation process (Ability 2 Innovate in EBM), automating the more mechanical team work, removing wasteful activities and running experiments may unlock more time from the teams to work in creating value.

If the organization is slow because its inefficient, adding more people will just make it even more inefficient. The other answers should be tried before adding more people.

Any investment strategy should be grounded of having transparency on the CV and UV of the products. Diluting the organizational focus across too many products may greatly impede producing ouotcomes from the product portfolio.

Increase the investment without any evidence is likely to be a highly inneficient investment strategy.

Investing only in products that already produce revenue is a short sigthed strategy. The mid and long term should also be considered.

Just waiting to see the results is not a strategy.

If the main product is mature and its lifecycle cannot be extended, the company is at risk. If that product stops providing profits, the company needs alternate sources of income. Start investing on new opportunities using the revenue of the current product is future-proofing the company.

Investing more resources on a product that is already fulfilling the user needs (hight Current Value) may be wasting your resources. When customers see new pottentially uneeded features they won’t get additional value and even feel that the product is needlessly complex.

Buying all the competitors may be a good commercial strategy on the short term, but as markets evolve, it’s not safe on the long term.

Investing based on sales or any decision which is not tied to the Unrealized Value (growth opportunities in the current or new markers) is an arbitrary decision which may not maximize the value to the users and to the company.

When it comes to select investments in our product portfolio, sales, cost/benefit ratio and product lifecycle are factors to consider. However, that does not tell what is the value delivered to customers. E.g. we can have a product delivering huge value to a small set of customers, that possibly cannot make a high sales figure.