Reframe the technical solution back to the business problem > One of the most important lessons in our industry is to fall in love with the problem, not the solution. > —Marty Cagan, Inspired > Right now your organization believes that everything revolves around you building software quickly and we are trying to get them understand that our success is a function of how many problems we solve and for who. > —Jeff Patton, from [Changing the game](https://youtu.be/OY4aAwbtV8s?t=2280) - It seems that organizations often operate more in the space of solutions. The prioritization and dev backlog seems to be such a proposals for technical solutions. - The actual business problem, however, seems to be out of visibility. - What is the *actual business problem* that we aim to tackle? - Has the solution actually helped in reaching the desired outcome? - A shared goal in form of a reachable leading metric might help us clarify the problem and validate our efforts - As a side-effect, such approach might align well with [[to work well, it seems to help to have psychological safety, with autonomy, opportunity for mastery and shared purpose|drives]] of autonomy, mastery and purpose - All efforts could then be geared towards lowering the metric ## Examples - quality - technical solution: asking to manually synchronize two systems for data that got out of sync - business problem: *quality* of information shown to users is poor - modification - technical solution: introducing a linter to the codebase and get alignment on some conventions - business problem: *modifying* a system takes long. ## Some ideas for choosing the problem - with goal-setting autonomy - choose the goal collaboratively (top-down as well as bottom-up): - question to ask: - if every area of our operation remained at its current level of performance, in which are would we want the most create a breakthrough? - alternatively, discover the big picture and the key hotspot with [[EventStorming]] session - without goal-setting autonomy: - for a given request to deliver a technical solution, ask: - Objective: What business objective is this work intended to address? - Key results: How will you know if you've succeeded? - Customer problem: What problem will this solve for our customers? - Target market: What type of customer are we focused on? ## Some possible traps for choosing the problem - Choosing too many problems to tackle at once - possible reasons for tackling multiple problems at once: - too much ambition with less focus - hedging your bets - requires to say "no" to a lot of good ideas - Choosing a problem that is too broad - Choosing a problem that is aspirational but not measurable - Choosing a problem that is not aligned to the vision of the organization ## It appears that having one goal at a time works better than more goals > Teams who try to focus on too many new goals at the same time usually wind up doing a mediocre job on all of them. > —[[The Four Disciplines of Execution]] > You have to decide what your highest priorities are and have the courage–pleasantly, smilingly, unapologetically—to say no to other things. And the way you do that is by having a bigger "yes" burning inside > — Stephen R. Covey FIXME: add thoughts from 4DX ## Further reading - Marty Cagan - Inspired - [[The Four Disciplines of Execution]] , - chapter 2 - Focus on the Wildly Important - chapter 6 - Choosing Where to Focus - [Introducing EventStorming - EventStorming](https://www.eventstorming.com/book/) ## Example ![[Screenshot 2022-04-22T18.40.png]]