When the expertise is part of the team but isn’t available when needed

In a traditional project and line organization, specialist expertise is often organized into functional units and shared across several projects. When planning a project, we estimate which skills will be needed, to what extent, and when. An architect might be allocated 20% of their time, a UX designer 30%, and another specialist full-time for a few weeks later in the project.

This approach makes sense when the work is predictable enough. If we can describe in advance what needs to be done and roughly when different skills will be required, we can plan people’s involvement accordingly. Specialists can contribute at the right time without being assigned to a project full-time.

But in complex product development, we cannot know in advance which solutions will achieve the outcomes we’re looking for. We need to experiment, gather feedback, and let what we learn shape what we do next. We often have a good idea of which skills we’ll need, but not which questions will arise, which perspectives will matter, or which decisions we’ll have to make along the way.

When we’re no longer working from a predefined solution that different specialists are expected to help implement, expertise takes on a different role. The team needs to discover and develop the solution together. Specialists contribute more than a specific piece of work. Their perspectives influence how the team understands the problem, which possibilities it considers, and what it decides to try. Architects aren’t only needed when an architectural decision has to be made, and UX expertise isn’t only valuable when something needs to be designed.

This is one of the reasons we build stable, cross-functional product teams. Different areas of expertise need to come together as the team’s understanding develops and solutions begin to take shape. The team needs to be able to explore questions together and make decisions as they arise.

This is where we risk falling into the Availability Trap.

We identify the expertise a product team needs but continue to plan people’s involvement as though we could predict exactly when their contributions will be required. We staff the team with 20% of one specialist, 30% of another, and perhaps a third full-time for a few weeks. On the organizational chart, the team looks cross-functional. But the staffing plan tells us nothing about whether the right people will be available to work together when questions actually arise.

In practice, a specialist whose perspective is needed may be working with another team. The people who need to work through a question together may not be available at the same time, or the authority to make a decision may rest with someone who isn’t there. The team ends up waiting or trying to coordinate everyone’s availability.

The same problem can occur when someone works full-time with the team for a limited period. Having a specialist available for three weeks doesn’t help if the critical question arises the following week. We may have followed the staffing plan perfectly and still find ourselves without the expertise we need.

But sometimes the problem is harder to spot. The team moves forward without a perspective that could have changed how it understood the problem or which solution it chose. Nobody notices what was missing, because nobody knew that particular expertise would be needed at that moment.

This doesn’t mean every specialist needs to be a full-time member of every team. Some expertise can be shared across teams. But the more frequently a particular skill is needed, the harder it is to predict when it will be needed, and the more important that perspective is to the team’s work, the harder it becomes to rely on scheduled contributions. The same applies to decision-making authority that the team regularly needs to exercise.

Leadership needs to change as well. Rather than primarily planning when specialists should carry out particular tasks, leaders need to make sure teams can draw on their expertise as questions emerge. This isn’t about making everyone available all the time. It’s about enabling teams to explore problems, develop solutions, and make decisions without having to schedule every specialist contribution in advance.

The Availability Trap occurs when we build cross-functional product teams but continue to plan access to expertise and decision-making authority as though we could predict when they will be needed. We have staffed the team with the right skills on paper, but haven’t created the conditions for that expertise to contribute when it matters most.

More traps

The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.

See the bigger picture

The classification trap in prioritization is one example of what can happen when we change the way we work without fully changing the underlying logic.

Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives including strategy, execution, governance, teams, funding, culture and organization.

When we build product teams but continue to optimize individual utilization

In a traditional project and line organization, specialist expertise is often organized into functional units. Line managers are responsible for matching skills and capacity to the needs of different projects. Architects, business analysts, developers, testers, and other specialists are assigned to projects, either part-time or full-time for limited periods.

This approach makes sense in that kind of organization. Line managers are expected to provide the right expertise at the right time while keeping people fully utilized. Optimizing resource utilization becomes part of doing a good job.

But moving to a product-oriented organization requires a different approach.

In complex product development, we cannot know in advance which solutions will achieve the desired outcomes. We need to explore, experiment, gather feedback, and learn. This is why we want stable, cross-functional product teams that can take responsibility for a product, work together over time, and continuously deliver value. Stability doesn’t mean that team membership can never change. It means having the continuity and collective capability needed to take ownership and deliver value over time.

This is where we risk falling into the Fragmentation Trap.

We create product teams but continue to allocate specialists across them to keep individual utilization high.

An architect is expected to do architecture work. When there isn’t enough architecture work in one team, we share the architect with another. A specialist who won’t be needed until later is brought in for a few weeks. And when the demand for a particular role temporarily decreases, we move that person to wherever their expertise is needed.

Each decision may seem perfectly reasonable. We make use of scarce expertise where it’s needed and avoid having people without enough work to do. But taken together, these decisions recreate the very fragmentation that stable product teams were intended to overcome.

When people split their time between several teams, they constantly switch between problems, priorities, and contexts. Research on task switching and attention residue shows that these transitions can come at a cost, making it harder to maintain focus.

Fragmentation also creates competing priorities. If a specialist works in two teams, each with its own backlog, who decides which work takes precedence? Allocating someone 50% to each team doesn’t resolve that question. It describes how their time is supposed to be divided, but not what should happen when both teams need them at the same time. Nor does it account for the time and effort involved in switching between different problems and contexts. Without shared prioritization, individuals may end up having to make these trade-offs themselves or negotiate between competing demands.

Short-term full-time assignments don’t create the same constant switching between teams. However, continuity can still be disrupted when a specialist moves on while work is still in progress. Knowledge and context may be lost, and when several teams depend on the same people, delays can spread between them. The result is more dependencies, more work in progress, and longer lead times.

This doesn’t mean specialist expertise should never be shared between teams. Temporary assignments can be valuable, and some capabilities may need to be shared. The difference is whether these arrangements strengthen teams’ ability to take responsibility for their work or leave them dependent on people constantly moving between teams.

This is also the difference between optimizing individual utilization and optimizing the flow of value through the organization. When we try to keep every specialist fully occupied, we risk creating waiting times, competing priorities, and more work in progress. Keeping everyone busy doesn’t necessarily mean more work gets finished. In fact, high utilization in parts of the system can make overall flow worse. This is a central idea in flow-based thinking and in Henrik Kniberg’s discussion of the Resource Utilization Trap.

Shared prioritization can help reduce competing demands between teams. But even when teams work towards the same priorities, the cost of switching contexts and disrupting continuity remains.

This also calls for a shift in leadership. In a traditional project and line organization, line managers largely work within the system, matching expertise to demand and allocating capacity within existing structures. In a product-oriented organization, leaders need to spend more time improving the system, creating the conditions for stable teams and an effective flow of value.

The Fragmentation Trap occurs when we build stable product teams but continue to optimize individual utilization. We keep people fully occupied, but in doing so, we risk making it harder for teams to stay focused, work together over time, and continuously deliver value.

More traps

The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.

See the bigger picture

The classification trap in prioritization is one example of what can happen when we change the way we work without fully changing the underlying logic.

Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives including strategy, execution, governance, teams, funding, culture and organization.

When we build product teams around roles rather than the capabilities they need

In a traditional project and line organization, work is often divided along specialist roles. Architects are responsible for architecture, developers for development, and testers for testing. When staffing a project, we identify which roles are needed and how many people we need in each area. Work is distributed among specialists and handed over as different parts are completed.

This approach makes sense when work can be broken down into activities that are planned and tracked separately. We develop deep expertise in each discipline and assign tasks to those best qualified to perform them. Leadership often follows the same logic. Managers set individual performance goals, track personal deliverables, and take responsibility for employees’ professional development. Role descriptions, objectives, and performance reviews reinforce expectations about what each person is supposed to contribute.

But moving to a product-oriented organization requires a different approach.

We want stable, cross-functional teams that can take responsibility for a product and the outcomes we aim to achieve. In complex product development, we cannot know in advance which solutions will work. Teams need to explore problems, test ideas, make decisions, and learn from the results. This means designing teams around their purpose. What problems do they need to solve? What decisions should they be able to make? What expertise do they need, and what capabilities must they develop to achieve their goals without unnecessary dependencies?

This is where we risk falling into the Role Trap.

When creating product teams, we often bring the roles from the project organization with us. We try to include every specialist role involved in the development process, even if some people only contribute a small part of their time. The result can be a large product team with many people and all the roles represented, but limited ability to work effectively together. We have all the roles covered, but we haven’t necessarily built the capabilities the team needs.

Once we organize around roles, they also tend to determine how work gets done. The architect handles architecture, the developer writes the code, and the tester does the testing. When development is finished, the work is handed over to testing. When an architectural question comes up, the team waits for the architect. And when the tester is overloaded, others may start new work rather than help finish what is already in progress.

We have moved the handovers inside the team, but we haven’t eliminated them.

Specialists become bottlenecks while others wait or start new tasks. The team becomes vulnerable when someone is absent, and knowledge remains concentrated in a few individuals. Individual performance goals can make matters worse. If developers are evaluated on their development output and testers on their testing output, focusing on their own tasks becomes the rational choice. Helping a colleague, learning something new, or solving a problem together may compete with what each person is expected to deliver.

We expect the team to take collective responsibility for results, yet we continue to manage and measure individual performance.

This doesn’t mean specialist expertise should disappear. Quite the opposite. We still need deep knowledge in different disciplines. But a team’s capability is more than the sum of its members’ individual expertise. In LeSS, the term generalizing specialists describes people who retain their deep expertise while broadening their ability to contribute in other areas. Not everyone needs to know everything, but more people need to be able to contribute across disciplines so the team becomes less dependent on specific individuals. Through multi-learning, where people learn from and with each other across specializations, the team gradually develops its collective capability.

This also changes what we need from leadership. Performance goals should be shared by the team, while individual goals should focus on learning and development. These goals need to reflect both personal ambitions and the capabilities the team needs to build. Sometimes that means deepening expertise, sometimes broadening it. Learning also needs to happen as part of everyday work.

Managers need to rethink how they follow up with individuals. If one-to-one conversations continue to focus on what each person has delivered, we risk recreating individual performance management alongside the team’s shared accountability. Managers still play an important role in supporting people’s growth, learning, and well-being, but they need to distinguish between team performance and individual development.

The Role Trap occurs when we build product teams around traditional specialist roles and continue to let those roles determine how work is divided, performance is measured, and skills are developed. Simply bringing people with different specializations together doesn’t make a team truly cross-functional. That starts when we design the team around its purpose and develop the ability to work and learn together.

More traps

The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.

See the bigger picture

The classification trap in prioritization is one example of what can happen when we change the way we work without fully changing the underlying logic.

Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives including strategy, execution, governance, teams, funding, culture and organization.

När vi bygger produktteam utifrån roller i stället för den förmåga teamet behöver

I en traditionell projekt- och linjeorganisation är arbetet ofta uppdelat efter specialistroller. Arkitekter ansvarar för arkitektur, utvecklare för utveckling och testare för testning. När ett projekt ska bemannas identifierar vi vilka roller som behövs och hur många personer som krävs inom varje område. Arbetet fördelas mellan specialisterna och lämnas vidare i takt med att olika delar blir färdiga.

Det är en naturlig logik när arbetet kan delas upp i aktiviteter som planeras och följs upp var för sig. Vi utvecklar djup kompetens inom respektive område och låter den som är bäst lämpad utföra uppgiften. Även ledarskapet utgår ofta från individen. Chefen sätter individuella prestationsmål, följer upp leveranser och ansvarar för medarbetarnas kompetensutveckling. Rollbeskrivningar, mål och uppföljning förstärker förväntningarna på vad var och en ska bidra med.

Men när vi går mot en produktorganisation behöver vi tänka annorlunda.

Vi vill bygga stabila, tvärfunktionella team som kan ta ansvar för en produkt och de effekter vi vill åstadkomma. I komplex produktutveckling vet vi inte på förhand vilka lösningar som kommer att fungera. Teamet behöver kunna utforska problem, prova idéer, fatta beslut och lära av resultatet. Därför behöver vi utgå från uppdraget när vi designar teamet. Vilka problem ska det kunna lösa? Vilka beslut behöver det kunna fatta? Vilken kompetens behöver finnas och vilken förmåga behöver teamet utveckla för att nå sina mål utan onödiga beroenden?

Men det är här vi riskerar att hamna i Rollfällan.

När vi skapar produktteam tar vi med oss rollerna från projektorganisationen. Vi försöker få med alla specialistroller som förekommer i utvecklingsprocessen, även om var och en bara bidrar med en liten del. Resultatet kan bli ett stort produktteam med många personer där alla roller finns representerade, men där förutsättningarna för gemensamt arbete är begränsade. Vi har bemannat alla roller, men inte nödvändigtvis byggt den förmåga teamet behöver.

När vi utgår från rollerna blir det också lätt att låta dem styra hur arbetet fördelas. Arkitekten ansvarar för arkitekturen, utvecklaren för utvecklingen och testaren för testningen. När utvecklaren är klar lämnas arbetet vidare till testaren. När en arkitekturfråga uppstår väntar teamet på arkitekten. Och när testaren har fullt upp fortsätter kanske andra med nya uppgifter i stället för att hjälpa till att få det pågående arbetet färdigt.

Vi har flyttat överlämningarna innanför teamets gränser, men inte fått bort dem.

Specialister blir flaskhalsar medan andra väntar eller påbörjar nytt arbete. Teamet blir sårbart när någon är frånvarande och kunskap koncentreras till enskilda personer. De individuella prestationsmålen kan dessutom förstärka problemet. Om utvecklaren bedöms utifrån sina leveranser och testaren utifrån sina tester blir det rationellt att prioritera de egna uppgifterna. Att hjälpa en kollega, lära sig något nytt eller lösa ett problem tillsammans kan då konkurrera med det individen förväntas prestera.

Vi vill att teamet ska ta gemensamt ansvar för resultatet, men fortsätter att styra och följa upp individuella prestationer.

Det betyder inte att specialistkompetensen ska försvinna. Tvärtom behöver vi djup kunskap inom olika områden. Men teamets förmåga är mer än summan av individernas specialistkunskaper. Inom LeSS används begreppet generalizing specialists för personer som behåller sin spetskompetens samtidigt som de breddar sin förmåga. Alla behöver inte kunna allt, men fler behöver kunna bidra inom olika områden så att teamet blir mindre beroende av enskilda personer. Genom multi-learning, där människor lär av och tillsammans med varandra över specialistgränserna, utvecklar teamet successivt sin gemensamma förmåga.

Det ställer också andra krav på ledarskapet. Prestationsmålen behöver vara gemensamma för teamet, medan individuella mål handlar om lärande och utveckling. De behöver ta hänsyn till både personliga ambitioner och den förmåga teamet behöver bygga. Ibland handlar det om att fördjupa en specialistkompetens, ibland om att bredda den. Lärandet behöver också vara en del av det dagliga arbetet.

Även chefens uppföljning behöver förändras. Om individuella 1:1-samtal fortsätter att handla om vad varje person levererar riskerar vi att återskapa individuell styrning vid sidan av teamets gemensamma ansvar. Chefen har fortfarande en viktig roll i att stödja individens utveckling, lärande och välmående, men behöver skilja på teamets prestation och individens utveckling.

Rollfällan uppstår när vi bygger produktteam utifrån traditionella specialistroller och fortsätter låta dessa styra hur arbetet fördelas, prestationer följs upp och kompetens utvecklas. Det är först när vi utgår från uppdraget och utvecklar förmågan att arbeta och lära tillsammans som vi börjar bygga ett verkligt tvärfunktionellt team.

Fler fällor

Det här är en av flera fällor i en serie: Fällor i övergången från projekt till produktteam.

Se helheten

Klassificeringsfällan i prioriteting är ett exempel på vad som kan hända när vi förändrar vårt sätt att arbeta utan att fullt ut förändra den underliggande logiken.

Vår poster Project vs Product Organization in a Nutshell belyser den här förflyttningen ur flera perspektiv – bland annat strategi, genomförande, styrning, team, finansiering, kultur och organisation.

När vi bygger produktteam men fortsätter optimera människors beläggning

I en traditionell projekt- och linjeorganisation är specialistkompetensen ofta organiserad i funktioner. Linjechefens uppgift är att matcha kompetens och kapacitet mot projektens behov. Arkitekter, kravanalytiker, utvecklare, testare och andra specialister fördelas mellan projekt, antingen på deltid eller i tidsbegränsade heltidsinsatser.

Det är en naturlig logik i den här typen av organisation. Linjechefen förväntas tillhandahålla rätt kompetens vid rätt tillfälle och samtidigt hålla beläggningen hög. Att optimera resursutnyttjandet blir en del av att göra ett bra jobb.

Men när vi går mot en produktorganisation vill vi åstadkomma något annat.

I komplex produktutveckling vet vi inte på förhand vilka lösningar som skapar önskad effekt. Vi behöver utforska, prova, få feedback och lära. Därför vill vi skapa stabila, tvärfunktionella produktteam som kan ta ansvar för en produkt, arbeta tillsammans över tid och kontinuerligt få värdefullt arbete färdigt. Stabilitet betyder inte att teamets sammansättning aldrig får förändras, utan att teamet har den kontinuitet och gemensamma förmåga som behövs för att ta ansvar och leverera värde över tid.

Men det är här vi riskerar att hamna i Fragmenteringsfällan.

Vi skapar produktteam, men fortsätter fördela specialister mellan dem för att hålla den individuella beläggningen hög.

En arkitekt förväntas arbeta med arkitektur. När det inte finns tillräckligt mycket arkitekturarbete i ett team delar vi personen med ett annat. En specialist som behövs först längre fram lånas in under några veckor. Och när behovet inom en viss roll tillfälligt minskar flyttar vi personen dit kompetensen för tillfället efterfrågas.

Varje beslut kan verka förnuftigt. Vi använder begränsad kompetens där den behövs och undviker att någon går utan uppgifter. Men tillsammans återskapar besluten just den fragmentering som de stabila produktteamen var tänkta att komma bort från.

När människor delar sin tid mellan flera team behöver de växla mellan problem, prioriteringar och sammanhang. Forskning om task switching och attention residue visar att sådana växlingar kan medföra omställningskostnader och göra det svårare att behålla fokus.

Fragmenteringen skapar också prioriteringskonflikter. Om en specialist arbetar i två team med varsin backlog, vem avgör vilket arbete som är viktigast? En fördelning på 50 procent i vardera teamet löser inte den frågan. Den säger hur personens tid är tänkt att fördelas, men inte vilket arbete som ska prioriteras när båda teamen behöver hjälp samtidigt. Den tar heller inte hänsyn till den tid och energi som går åt till att växla mellan olika problem och sammanhang. Utan en gemensam prioritering riskerar individen att själv behöva avgöra vad som ska göras först eller förhandla mellan konkurrerande behov.

Tidsbegränsade heltidsinsatser skapar inte samma ständiga växling mellan team. Däremot kan kontinuiteten brytas när en specialist flyttas vidare medan arbetet fortfarande pågår. Kunskap och sammanhang riskerar att gå förlorade, och när flera team är beroende av samma människor kan förseningar spridas mellan dem. Resultatet blir fler beroenden, mer pågående arbete och längre ledtider.

Det betyder inte att specialistkompetens aldrig kan delas mellan team. Tidsbegränsade insatser kan vara värdefulla, och vissa kompetenser kan behöva vara gemensamma. Skillnaden ligger i om insatserna stärker teamens förmåga att ta ansvar för sitt arbete eller om teamen blir beroende av att människor ständigt flyttas mellan dem.

Här ligger också skillnaden mellan att optimera människors individuella beläggning och att optimera flödet av värde genom organisationen. När vi försöker hålla varje specialist fullt sysselsatt riskerar vi att skapa väntetider, konkurrerande prioriteringar och mer pågående arbete. Att alla har fullt upp betyder inte att organisationen får mycket arbete färdigt. Tvärtom kan hög beläggning i delar av systemet försämra flödet i helheten. Det är en central tanke i flödesprinciper och i Henrik Knibergs resonemang om Resource Utilization Trap.

En gemensam prioritering av arbetet kan minska konkurrerande behov mellan team. Men även om teamen arbetar mot samma prioriteringar kvarstår kostnaden för att människor behöver växla mellan olika sammanhang och att kontinuiteten bryts.

Det kräver också en förändring i ledarskapet. I projekt- och linjeorganisationen arbetar linjechefen till stor del i systemet, genom att matcha kompetens mot behov och fördela kapacitet utifrån befintliga strukturer. I produktorganisationen behöver ledarskapet i högre grad utveckla systemet, genom att skapa förutsättningar för stabila team och ett effektivt flöde av värde.

Fragmenteringsfällan uppstår när vi bygger stabila produktteam men fortsätter optimera människors individuella beläggning. Vi håller människor fullt sysselsatta, men riskerar samtidigt att göra det svårare för teamen att behålla fokus, arbeta tillsammans över tid och få värdefullt arbete färdigt.

Fler fällor

Det här är en av flera fällor i en serie: Fällor i övergången från projekt till produktteam.

Se helheten

Klassificeringsfällan i prioriteting är ett exempel på vad som kan hända när vi förändrar vårt sätt att arbeta utan att fullt ut förändra den underliggande logiken.

Vår poster Project vs Product Organization in a Nutshell belyser den här förflyttningen ur flera perspektiv – bland annat strategi, genomförande, styrning, team, finansiering, kultur och organisation.

När kompetensen finns i teamet men inte när den behövs

I en traditionell projekt- och linjeorganisation är specialistkompetensen ofta organiserad i funktioner och delas mellan flera projekt. När ett projekt planeras uppskattar vi vilken kompetens som behövs, i vilken omfattning och vid vilken tidpunkt. En arkitekt kanske behövs på 20 procent, en UX-designer på 30 procent och en annan specialist på heltid under några veckor längre fram i projektet.

Det är en naturlig logik när arbetet går att förutse tillräckligt väl. Om vi på förhand kan beskriva vad som ska göras och ungefär när olika kompetenser behövs, kan vi också planera människors insatser. Specialister kan bidra vid rätt tillfälle utan att vara knutna till ett projekt på heltid.

Men i komplex produktutveckling vet vi inte på förhand vilka lösningar som kommer att skapa önskad effekt. Vi behöver prova oss fram, få feedback och låta det vi lär oss påverka vad vi gör härnäst. Vi vet ofta vilka kompetenser som sannolikt behövs, men inte vilka frågor som kommer att uppstå eller vilka perspektiv och beslut som kommer att behövas längs vägen.

När vi inte längre utgår från en färdig lösning som olika specialister ska bidra till att genomföra får kompetensen en annan roll. Teamet behöver tillsammans upptäcka och utveckla lösningen. En specialist bidrar inte bara med en viss insats, utan också med perspektiv som påverkar hur teamet förstår problemet, vilka möjligheter det ser och vad det väljer att prova. Arkitekten behövs inte bara när ett arkitekturbeslut ska fattas och UX-kompetensen inte bara när något ska designas.

Det är en av anledningarna till att vi bygger stabila, tvärfunktionella produktteam. Olika kompetenser behöver kunna mötas medan förståelsen och lösningen växer fram. Teamet behöver kunna utforska frågor tillsammans och fatta beslut när de behövs.

Men det är här vi riskerar att hamna i Tillgänglighetsfällan.

Vi identifierar vilka kompetenser produktteamet behöver men fortsätter planera deras medverkan som om vi på förhand kunde veta när de behövs. Vi bemannar teamet med 20 procent av en specialist, 30 procent av en annan och kanske en tredje på heltid under några veckor. På organisationsbilden ser teamet tvärfunktionellt ut. Men bemanningsplanen säger inget om huruvida rätt kompetenser kan mötas när frågorna faktiskt uppstår.

I praktiken kanske en specialist vars perspektiv behövs arbetar i ett annat team. De kompetenser som behöver mötas är kanske inte tillgängliga samtidigt, eller så finns mandatet för ett beslut hos någon som inte är där. Teamet får vänta och samordna.

Det gäller även när någon arbetar heltid i teamet under en begränsad period. Att en specialist finns tillgänglig under tre veckor hjälper inte om den avgörande frågan uppstår veckan efter. Vi kan ha planerat insatsen helt enligt plan och ändå sakna kompetensen när den behövs.

Men ibland uppstår ett problem som är svårare att upptäcka. Teamet går vidare utan ett perspektiv som hade kunnat förändra både förståelsen av problemet och valet av lösning. Ingen märker vad som saknades, eftersom ingen visste att kompetensen skulle behövas just då.

Det betyder inte att all specialistkompetens måste finnas på heltid i varje team. Viss expertis kan delas mellan flera team. Men ju oftare en kompetens behöver bidra, ju svårare det är att förutse när den behövs och ju viktigare dess perspektiv är för teamets arbete, desto svårare blir det att hantera den som en insats som kan planeras in vid vissa tillfällen. Detsamma gäller mandat för beslut som teamet återkommande behöver kunna fatta.

Även ledarskapet behöver förändras. I stället för att främst planera när olika specialister ska utföra sina uppgifter behöver ledare se till att teamet kan dra nytta av deras kompetens när frågorna uppstår. Det handlar inte om att alla ska vara tillgängliga hela tiden, utan om att teamet ska kunna utforska problem, utveckla lösningar och fatta beslut utan att varje specialistinsats måste planeras i förväg.

Tillgänglighetsfällan uppstår när vi bygger tvärfunktionella produktteam men fortsätter planera tillgången till kompetens och mandat som om vi på förhand kunde veta när de kommer att behövas. Vi har bemannat teamet med rätt kompetenser på papperet, men inte skapat förutsättningarna för att de ska kunna bidra när det verkligen behövs.

Fler fällor

Det här är en av flera fällor i en serie: Fällor i övergången från projekt till produktteam.

Se helheten

Klassificeringsfällan i prioriteting är ett exempel på vad som kan hända när vi förändrar vårt sätt att arbeta utan att fullt ut förändra den underliggande logiken.

Vår poster Project vs Product Organization in a Nutshell belyser den här förflyttningen ur flera perspektiv – bland annat strategi, genomförande, styrning, team, finansiering, kultur och organisation.

In a project and line organization, responsibility is often divided across functions, departments and managers. Each has its own goals, budget and responsibilities, and projects are set up to deliver initiatives that cut across the organization.

When there is not enough capacity to do everything, different needs have to be weighed against each other. Negotiation naturally becomes part of prioritization. Each person represents their area and makes the case for what matters there.

This customer is waiting.
We have already promised this.
We need to address this risk.
This is critical to our revenue.

These can all be perfectly reasonable arguments. They reflect the responsibilities people have actually been given.

As we move towards outcome-driven steering and stable cross-functional product teams, the logic starts to change. Instead of bringing people together temporarily around different initiatives, we have stable capacity that can be used to create change over time. And outcomes such as increased customer loyalty, shorter lead times or better quality rarely fit neatly within organizational boundaries.

The question is therefore no longer primarily who should get resources for their initiative, but which outcome matters most right now and should get our limited capacity.

But the old logic can remain.

We can have stable cross-functional teams and Epics that describe desired outcomes, while different parts of the organization continue to compete for the teams’ capacity.

We have changed the structure around prioritization, but prioritization itself is still a negotiation between organizational interests.

When each alternative is argued from a different perspective, they also become difficult to compare. One case is made in terms of customer value, another in terms of revenue and a third in terms of risk. They may all be important, but they are being judged by different measures.

Without a shared basis for the decision, something else eventually has to settle it. It may be what has already been promised, who makes the strongest case or who has the most influence.

Or HiPPO: Highest Paid Person’s Opinion.

The real problem is not HiPPO. The problem is that we have created a prioritization system in which we need a HiPPO to move forward.

To make priorities across the organization, we need a shared basis for our decisions. A clear strategic ambition provides direction, but it is not always enough. Several possible outcomes may contribute to the same ambition, so we still need a way to decide what should take priority.

Strategic contribution, expected outcome, time criticality, risk and the capacity required may all matter. The challenge is to consider them together and compare the alternatives relative to each other, rather than having each part of the organization make its case using its own criteria.

There is a lot we can learn here from the economic thinking behind approaches such as Cost of Delay. The point is not to find a formula that gives us the right answer, but to create a better basis for weighing different perspectives and alternatives against each other.

That is The Negotiation Trap in Prioritization: we have moved from projects to product teams and started describing the outcomes we want to achieve, but different parts of the organization are still negotiating over the same limited capacity.

The shift is from negotiating between local interests to making shared priorities based on what matters most for the organization as a whole.

More traps

The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.

See the bigger picture

The negotiation trap in prioritization is one example of what can happen when we change the way we work without fully changing the underlying logic.

Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives including strategy, execution, governance, teams, funding, culture and organization.

I en projekt- och linjeorganisation är ansvar ofta fördelat mellan funktioner, avdelningar och chefer. Varje del har sina mål, sin budget och sitt ansvar, och projekt startas för att

genomföra olika initiativ tvärs över organisationen.

När resurserna inte räcker till allt behöver olika behov vägas mot varandra. Då blir förhandling en ganska naturlig del av prioriteringen. Varje ansvarig företräder sitt område och argumenterar för det som är viktigt där.

Den här kunden väntar.
Det här har vi redan lovat.
Den här risken måste vi hantera.
Det här är avgörande för våra intäkter.

Argumenten kan vara helt rimliga. De speglar det ansvar människor faktiskt har fått.

När vi går mot effektstyrning och stabila tvärfunktionella produktteam förändras förutsättningarna. I stället för att samla människor kring olika initiativ har vi en stabil kapacitet som kan användas för att åstadkomma förflyttningar över tid. Och effekter som ökad kundlojalitet, kortare ledtider eller bättre kvalitet följer sällan organisationens gränser.

Frågan blir därför inte i första hand vem som ska få resurser till sitt initiativ, utan vilken förflyttning som är viktigast att åstadkomma nu och därför ska få vår begränsade kapacitet.

Men den gamla logiken kan leva kvar.

Vi kan ha stabila tvärfunktionella team och Epics som beskriver önskade förflyttningar, samtidigt som olika delar av organisationen fortsätter konkurrera om teamens kapacitet.

Vi har förändrat strukturen runt prioriteringen, men själva prioriteringen är fortfarande en förhandling mellan organisatoriska intressen.

När varje alternativ dessutom motiveras utifrån sitt eget perspektiv blir de svåra att jämföra. Det ena argumentet handlar om kundvärde, det andra om intäkter och det tredje om risk. Alla kan vara viktiga, men de bedöms utifrån olika måttstockar.

Om vi saknar en gemensam grund för beslutet måste något annat till slut avgöra. Det kan vara det som redan har lovats, den som argumenterar bäst eller den som har mest makt.

Eller HiPPO: Highest Paid Person’s Opinion.

Problemet är inte egentligen HiPPO. Problemet är att vi har skapat ett prioriteringssystem där vi behöver en HiPPO för att komma vidare.

För att prioritera för helheten behöver vi en gemensam grund för våra beslut. En tydlig strategisk ambition ger riktning, men den räcker inte alltid. Flera möjliga förflyttningar kan bidra till samma ambition och då behöver vi också kunna avgöra vad som ska få en förflyttning att gå före en annan.

Det kan handla om strategiskt bidrag, förväntad effekt, tidskritikalitet, risk eller hur mycket kapacitet något kräver. Utmaningen är att väga perspektiven tillsammans och jämföra alternativen relativt varandra, snarare än att låta varje del av organisationen argumentera utifrån sin egen måttstock.

Här finns mycket att hämta i det ekonomiska tänkandet bakom exempelvis Cost of Delay. Poängen är inte att hitta en formel som ger oss det rätta svaret, utan att hjälpa oss väga olika perspektiv och alternativ mot varandra.

Det är Förhandlingsfällan i prioritering: vi har gått från projekt till produktteam och börjat formulera önskade förflyttningar, men låter fortfarande olika delar av organisationen förhandla om den begränsade kapaciteten.

Förflyttningen är från att förhandla mellan lokala intressen till att tillsammans prioritera det som är viktigast för helheten.

Fler fällor

Det här är en av flera fällor i en serie: Fällor i övergången från projekt till produktteam.

Se helheten

Klassificeringsfällan i prioriteting är ett exempel på vad som kan hända när vi förändrar vårt sätt att arbeta utan att fullt ut förändra den underliggande logiken.

Vår poster Project vs Product Organization in a Nutshell belyser den här förflyttningen ur flera perspektiv – bland annat strategi, genomförande, styrning, team, finansiering, kultur och organisation.

När vi går från att organisera arbete i projekt till att arbeta i produktteam förändras inte bara organisationsformen. Även logiken för hur vi prioriterar, planerar, organiserar och följer upp arbetet behöver förändras.

Det är lätt att byta språk och strukturer utan att förändra den underliggande logiken. Krav blir Epics, projektplaner blir Product Backlogs och vi inför nya sätt att visualisera arbetet, samtidigt som vi fortsätter fatta beslut och styra ungefär som tidigare.

På ytan kan mycket alltså se annorlunda ut, medan gamla sätt att tänka lever kvar. Vi bestämmer fortfarande lösningar tidigt, klassificerar vad som ska få plats i projektets scope, bryter ner redan bestämda lösningar i mindre delar, låter några få planera åt många och följer upp om det planerade arbetet blir gjort.

Språket har förändrats. Strukturerna har förändrats. Men logiken bakom hur vi styr och organiserar arbetet är densamma.

Det här fällor som jag återkommande ser i den förflyttningen.

Det som förenar fällorna är att vi kan förändra strukturerna utan att förändra tankesättet bakom dem. Vi kan kalla något en Epic och fortfarande behandla den som ett stort krav. Vi kan ha en Product Backlog och fortfarande använda den som en projektplan. Vi kan ha produktteam och fortfarande bestämma vad de ska göra långt i förväg.

Att gå över till produktteam betyder inte att vi slutar planera, formulera krav, leverera eller synliggöra arbetet. Det som förändras är vad vi använder dessa saker till.

Utmaningen är inte att införa nya strukturer. Det är att upptäcka när vi använder dem för att fortsätta arbeta enligt samma gamla projektlogik.

Se helheten

Förflyttningen från projekt till produktteam påverkar fler delar av organisationen, bland annat strategi, styrning, finansiering, team, kultur och organisationsstruktur.

Vår poster Project vs Product Organization in a Nutshell visar den större förflyttningen ur flera perspektiv.

When we move from organizing work in projects to working in product teams, it is not only the organizational structure that changes. The logic behind how we prioritize, plan, organize, and track the work also needs to change.

It is easy to change the language and structures without changing the underlying logic. Requirements become Epics, project plans become Product Backlogs, and new ways of visualizing the work are introduced, while we continue to make decisions and manage the work much as we did before.

From the outside, the organization may look very different. But underneath, familiar assumptions can remain. We still decide solutions early, classify what should fit into scope, break predefined solutions into smaller pieces, let a few people plan for everyone else, and track whether the planned work gets done.

The terminology has changed. The structures have changed. But the logic for managing the work has not.

These are traps I repeatedly see in that shift.

What connects these traps is the risk of changing the visible structures without changing the assumptions behind them. We can call something an Epic and still treat it as a large requirement. We can have a Product Backlog and still use it as a project plan. We can have product teams and still decide their work far in advance.

Moving to product teams does not mean that planning, requirements, delivery or making work visible no longer matter. It changes what we use them for.

The challenge is not adopting the structures of product teams. It is recognizing when we are using those structures to reproduce the logic of projects.

See the bigger picture

These traps focus on how we organize and manage work. The move from projects to product teams affects many other parts of the organization as well, including strategy, governance, funding, teams, culture and organizational structure.

Our Project vs Product Organization in a Nutshell poster explores this broader shift from several perspectives.

I en projektorganisation sker prioritering ofta i samband med att vi bestämmer vad som ska ingå i ett projekt. Vi har krav, funktioner eller lösningar och behöver avgöra vad som ska få plats inom en begränsad tid och budget.

Ett naturligt sätt att göra det är att klassificera innehållet: High, Medium eller Low, Must, Should eller Could. Det hjälper oss att skilja det som måste ingå i leveransen från sådant vi kan avstå från om tiden eller pengarna inte räcker. Flera saker kan vara High eller Must samtidigt. Det är inget konstigt med det. Vi försöker framför allt avgöra vad som ska ingå i det scope vi planerar att leverera.

När vi organiserar utvecklingen kring produktteam förändras frågan. Vi arbetar mot önskade effekter och behöver avgöra vilken förflyttning som är viktigast att fokusera på nu.

Det kräver någon form av gemensam grund för våra val. Strategisk betydelse kan spela in, liksom förväntad effekt, tidskritikalitet, risk och hur mycket kapacitet något kräver. Exakt vilka principer vi använder är mindre viktigt än att vi är överens om dem innan vi börjar argumentera för våra egna förflyttningar.

Prioritering uppstår egentligen först när alternativen ställs mot varandra. Vad händer om vi väntar med den ena medan vi gör den andra? Vad kostar det oss att vänta? Vad får vi genom den ordning vi väljer, och vad väljer vi samtidigt att skjuta på? Det är samma typ av ekonomiskt resonemang som ligger bakom exempelvis Cost of Delay och Weighted Shortest Job First.

Men när vi går från att organisera utvecklingen i projekt till att arbeta i produktteam följer ofta ett välbekant sätt att prioritera med oss. Kraven och lösningarna har kanske ersatts av Epics som beskriver önskade förflyttningar, men vi fortsätter att prioritera dem på ett välbekant sätt:

Öka kundlojaliteten: High.
Minska tiden för onboarding: High.
Minska återkommande produktionsincidenter: High.
Öka självservicen: Medium.

Det ser ut som att vi har prioriterat våra förflyttningar. Men vilken ska vi fokusera på först?

När varje Epic bedöms för sig är det lätt att nästan allt blir High. Kundlojaliteten är avgörande för affären, problemen i onboarding gör att vi tappar kunder och produktionsincidenterna kostar pengar och skapar frustration. Självservice kan samtidigt frigöra betydande kapacitet. Alla har bra argument, och om Low i praktiken riskerar att betyda inte nu och kanske aldrig finns det starka incitament att åtminstone hamna på Medium, helst High.

Efter ett tag har vi kanske fem High, tre Medium och en Low. Vi har lagt mycket tid på prioritering, men fortfarande inte bestämt vad som ska gå först.

Vi har klassificerat hur viktiga saker är. Vi har inte prioriterat mellan dem.

En rak prioriteringsordning, eller stack ranking, tvingar fram ett annat beslut. Inte för att siffrorna 1, 2 och 3 är bättre etiketter, utan för att något faktiskt måste gå före något annat. Om något flyttas upp behöver något annat flyttas ner.

Två saker kan båda vara High. De kan inte båda vara först.

Det betyder inte att ordningen blir en ny plan för framtiden. När vi lär oss mer, uppnår effekter eller förutsättningarna förändras kan också ordningen förändras. Den visar helt enkelt vårt bästa beslut just nu om var vi ska lägga vår begränsade kapacitet.

Klassificeringsfällan i prioritering uppstår när vi prioriterar varje Epic för sig, när vi egentligen behöver prioritera mellan dem.

Fler fällor

Det här är en av flera fällor i en serie: Fällor i övergången från projekt till produktteam

Se helheten

Klassificeringsfällan i prioriteting är ett exempel på vad som kan hända när vi förändrar vårt sätt att arbeta utan att fullt ut förändra den underliggande logiken.

Vår poster Project vs Product Organization in a Nutshell belyser den här förflyttningen ur flera perspektiv – bland annat strategi, genomförande, styrning, team, finansiering, kultur och organisation.

In a project organization, prioritization often happens when we decide what should be included in a project. We have requirements, features, or solutions and need to determine what can fit within a limited timeframe and budget.

A natural way to do this is to classify the work: High, Medium, or Low, Must, Should, or Could. This helps us distinguish what needs to be part of the delivery from what we can leave out if time or money runs short. Several things can be High or Must at the same time. There is nothing strange about that. We are primarily trying to decide what should be included in the scope we plan to deliver.

When we organize development around product teams, the question changes. We work towards desired outcomes and need to decide which outcome matters most right now and where to focus our capacity.

To make that choice, we need some shared principles for prioritization. Strategic importance may matter, as well as expected impact, time criticality, risk, or how much capacity something requires. The exact principles matter less than agreeing on them before we start arguing for the things we each care about most.

Prioritization really begins when we compare alternatives. What happens if we delay one while pursuing another? What does waiting cost us? What do we gain from the order we choose, and what do we postpone as a result? This is the kind of economic thinking behind approaches such as Cost of Delay and Weighted Shortest Job First.

But when we move from organizing development in projects to working in product teams, a familiar way of prioritizing often comes with us. Requirements and solutions may have been replaced by Epics describing desired outcomes, but we continue to prioritize them in much the same way:

Increase customer loyalty: High.
Reduce onboarding time: High.
Reduce recurring production incidents: High.
Increase self-service: Medium.

It looks like we have prioritized our Epics. But which one should we focus on first?

When each Epic is assessed on its own, it is easy for almost everything to become High. Customer loyalty is critical to the business, onboarding problems are causing us to lose customers, and production incidents cost money and create frustration. Self-service could free up significant capacity. They all have good arguments. And if Low effectively means not now and perhaps never, there is a strong incentive to make sure your own Epic is at least Medium, preferably High.

Before long, we may have five Highs, three Mediums, and one Low. We have spent a lot of time prioritizing, but we still haven’t decided what should come first.

We have classified how important things are. We haven’t prioritized between them.

A clear priority order, or stack ranking, forces a different decision. Not because 1, 2, and 3 are better labels than High, Medium, and Low, but because something actually has to come before something else. If one thing moves up, another has to move down.

Two things can both be High. They cannot both be first.

This does not mean the order becomes a new plan for the future. As we learn more, achieve outcomes, or circumstances change, the order can change too. It simply represents our best decision right now about where to focus our limited capacity.

The Classification Trap in Prioritization occurs when we prioritize each Epic on its own, when what we really need to do is prioritize between them.

More traps

The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.

See the bigger picture

The classification trap in prioritization is one example of what can happen when we change the way we work without fully changing the underlying logic.

Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives including strategy, execution, governance, teams, funding, culture and organization.

I en projektorganisation definierar vi vad som ska levereras, organiserar arbetet och följer upp hur det går. Scope bryts ner, aktiviteter planeras och status rapporteras. Vi kan se vad som är gjort, vad som återstår och om leveransen följer planen.

När vi går mot produktutveckling förändras målet. Vi försöker inte längre slutföra en på förhand definierad mängd arbete, utan åstadkomma en förflyttning; en effekt för kunder, användare eller verksamheten. Då förändras också vad vi behöver styra och följa upp.

Vi behöver fortfarande förstå vad som pågår, vad vi lägger vår kapacitet på och vad som hindrar oss. Men det utförda arbetet är inte längre det primära måttet på framsteg.

Det räcker inte att veta vad vi har gjort. Vi behöver veta vad det har lett till.

Ändå är det förvånansvärt lätt att införa produktbackloggar, Epics, Stories, Tasks och tavlor och samtidigt ta med sig den gamla logiken. Projektplanen har försvunnit, men frågorna är nästan desamma: Vad är klart? Vad återstår? Hur mycket har vi levererat? Följer vi planen?

Mer av arbetet har blivit synligt, men vi använder fortfarande strukturen framför allt för att följa arbetet och kontrollera vad som blir gjort.

Här finns en viktig skillnad mellan transparens och kontroll. I produktutveckling gör vi arbetet synligt för att de som arbetar med och finansierar produkten ska kunna förstå vad som händer, samordna sig, skapa lärande och fatta bättre beslut om vad som är klokt att göra härnäst.

Samma transparens kan användas för två helt olika syften: för att kontrollera arbetet eller för att styra mot effekt.

Kontrollogiken blir särskilt synlig när vi försöker ge allt arbete en plats i strukturen. Det kommer alltid att finnas underhåll, support, mindre rättningar, tekniskt arbete och annat som behöver hanteras, utan att det direkt kommer ur de förflyttningar vi har valt att åstadkomma.

Här är det lätt att börja använda Epics till något de inte är avsedda för: som behållare för olika typer av arbete. Underhållsuppgifter samlas kanske i en Epic som heter Underhåll, supportuppgifter i Support. Backloggen ser prydlig ut och allt har fått sin plats.

Men då har vi också tappat själva poängen med en Epic. Vad innebär det egentligen att prioritera Underhåll högre än Support? Enskilda uppgifter kan vara mer eller mindre viktiga, men behållarna beskriver inga förflyttningar vi kan välja mellan. De blir heller aldrig klara, eftersom nytt arbete hela tiden fylls på.

En Epic är inte en behållare för arbete. Den representerar en förflyttning vi vill åstadkomma.

Minska återkommande produktionsincidenter med 50 procent kan till exempel vara en Epic som beskriver en intern förbättring. Få dubbelt så många förstagångskunder att komma tillbaka inom en månad kan vara en annan, med en mer direkt effekt för kunden och verksamheten. Båda beskriver förflyttningar som vi kan prioritera mot andra förflyttningar, arbeta mot, mäta och så småningom uppnå.

Vissa underhållsuppgifter kanske bidrar till den första Epicen, andra gör det inte. Allt kan ändå vara synligt i produktbackloggen. En Task behöver inte en Epic bara för att ha någonstans att höra hemma.

Skillnaden mellan att följa upp arbete och att styra mot effekt blir kanske allra tydligast när vi upptäcker att vi inte behöver göra allt vi trodde.

Anta att vi tror att tio saker behövs för att skapa en viss effekt. Vi gör tre, mäter vad som händer och upptäcker att effekten redan är uppnådd.

Om vi följer upp arbetet ser vi sju saker som återstår. Om vi följer upp effekten har vi upptäckt sju saker som vi inte behöver göra.

Samma verklighet. Helt olika syn på framsteg.

Vi behöver inte heller känna till eller strukturera allt arbete i förväg. Incidenter, supportärenden och annat oplanerat arbete kommer att ta kapacitet utan att vi vet exakt vad det blir. Vi kan lämna utrymme för det och synliggöra arbetet när det uppstår. Och allt behöver inte bli en entitet i backloggen, bara för att arbetet går att följa upp betyder det inte att det är värdefullt att göra det.

Vi behöver alltså fortfarande förstå arbetet, kapaciteten och vad som händer. Men vi behöver inte bygga vår styrning kring att kontrollera att arbetet blir gjort.

Kontrollfällan uppstår när vi inför produktutvecklingens strukturer och transparens men fortsätter använda dem med projektlogikens fokus på scope, leverans och genomfört arbete och blir bättre på att följa upp vad vi gör än på att förstå vad vi åstadkommer.

Fler fällor

Det här är en av flera fällor i en serie: Fällor i övergången från projekt till produktteam

Se helheten

Kontrollfällan är ett exempel på vad som kan hända när vi förändrar vårt sätt att arbeta utan att fullt ut förändra den underliggande logiken.

Vår poster Project vs Product Organization in a Nutshell belyser den här förflyttningen ur flera perspektiv – bland annat strategi, genomförande, styrning, team, finansiering, kultur och organisation.

In a project organization, we define what needs to be delivered, organize the work and follow its progress. Scope is broken down, activities are planned and status is reported. We can see what has been done, what remains and whether delivery is following the plan.

When we move towards product development, the goal changes. We are no longer trying to complete a predefined body of work, but to create a change; an effect for customers, users or the business. And that changes what we need to steer towards and measure.

We still need to understand what is happening, where our capacity goes and what is getting in our way. But the work itself is no longer our primary measure of progress.

It is not enough to know what we have done. We need to know what it has led to.

Yet it is surprisingly easy to introduce Product Backlogs, Epics, Stories, Tasks and boards while bringing the old logic with us. The project plan has disappeared, but the questions remain much the same: What is done? What is left? How much have we delivered? Are we following the plan?

More of the work has become visible, but we are still using the structure primarily to follow the work and control what gets done.

This is where the distinction between transparency and control becomes important. In product development, we make work visible so that the people working with and funding the product can understand what is happening, coordinate, learn and make better decisions about what to do next.

The same transparency can serve two very different purposes: controlling the work or steering towards outcomes.

The control logic becomes particularly visible when we try to give all work a place in the structure. There will always be maintenance, support, smaller fixes, technical work and other things that need attention without coming directly from the changes we have chosen to pursue.

This is where it is easy to start using Epics for something they are not intended for: as containers for different types of work. Maintenance Tasks might be collected under an Epic called Maintenance, support Tasks under Support. The backlog looks tidy and everything has found its place.

But in doing so, we have also lost the point of an Epic. What does it actually mean to prioritize Maintenance over Support? Individual Tasks within them may be more or less important, but the containers do not describe changes we can choose between. Nor do they ever finish, because new work keeps arriving.

An Epic is not a container for work. It represents a change we want to achieve.

Reduce recurring production incidents by 50 percent could, for example, be an Epic describing an internal improvement. Get twice as many first-time customers to return within a month could be another, with a more direct effect on customers and the business. Both describe changes we can prioritize against other changes, work towards, measure and eventually achieve.

Some maintenance Tasks may contribute to the first Epic, while others do not. All of them can still be visible in the Product Backlog. A Task does not need an Epic simply to have somewhere to belong.

The difference between tracking work and steering towards outcomes becomes perhaps clearest when we discover that we do not need to do everything we thought we would.

Suppose we believe ten things are needed to create a certain effect. We do three, measure what happens and discover that the effect has already been achieved.

If we follow up on the work, we see seven things remaining. If we follow up on the effect, we have discovered seven things we do not need to do.

Same reality. A completely different view of progress.

Nor do we need to know or structure all work in advance. Incidents, support requests and other unplanned work will consume capacity without us knowing exactly what it will be. We can leave room for it and make the work visible when it appears. And not everything needs to become a backlog item – just because work can be tracked does not mean there is value in tracking it.

We still need to understand the work, our capacity and what is happening. But we do not need to build our governance around controlling whether the work gets done.

The Control Trap happens when we introduce product structures and transparency but continue to use them with the project logic of focusing on scope, delivery and completed work: becoming better at tracking what we do than at understanding what we achieve.

More traps

The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.

See the bigger picture

The control trap is one example of what can happen when we change the way we work without fully changing the underlying logic.

Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives — including strategy, execution, governance, teams, funding, culture and organization.

När vi har något stort framför oss behöver vi dela upp det i mindre, hanterbara delar. Om vi vet vilken lösning som behövs är det ganska okomplicerat. Ett huvudkrav kan brytas ner i systemkrav och sedan i allt mer detaljerade krav. Delarna blir mindre, men de är fortfarande delar av en helhet som redan är definierad. Vi bygger dem, sätter ihop dem och testar den färdiga lösningen.

I komplexitet fungerar det annorlunda. När effekten av det vi bygger beror på hur människor agerar eller hur ett större system reagerar kan vi inte veta på förhand vilken lösning som kommer att skapa den effekt vi vill uppnå. Vi kan ha data, erfarenhet och goda skäl att tro på en lösning, men tills vi ser vad som faktiskt händer har vi en hypotes, inte ett svar.

En effektorienterad Epic börjar därför inte med vad vi ska bygga, utan med den förändring vi vill åstadkomma. Till exempel: Öka andelen förstagångsgäster på restaurangen som kommer tillbaka inom två veckor från 18 till 35 procent. Vi vet vart vi vill, men ännu inte vad som behöver byggas för att komma dit.

Därför kan vi heller inte på förhand bryta ner Epicen i alla Stories som kommer att behövas. Istället väljer vi en liten bit fungerande funktionalitet som vi tror kan föra oss närmare den önskade effekten. Vi bygger den, ser vad som händer och låter det vi lär oss påverka vad vi väljer att bygga härnäst. Arbetet blir både inkrementellt och iterativt: vi bygger något fungerande samtidigt som vi lär oss vad nästa steg behöver vara.

Det avgörande är alltså inte hur små delarna är, utan vad de är delar av. Vid nedbrytning är de delar av en lösning vi redan har bestämt oss för att bygga. Med slicing är de istället steg mot en effekt, där varje steg ger oss möjlighet att lära innan vi bestämmer nästa.

Det lämnar också mer av problemlösningen till teamet. Istället för att få en lösning där de viktigaste besluten redan är fattade kan teamet använda sin samlade kompetens, tillsammans med det användarna och systemet visar oss, för att avgöra vad som är värt att bygga härnäst.

Ibland är det mest värdefulla vi lär oss att vi inte behöver bygga det vi trodde från början. Om tre Stories skapar tillräckligt av den önskade effekten finns det kanske ingen anledning att bygga Story fyra till tio. De är inte ogjort arbete. De är sådant vi upptäckte att vi inte behövde bygga. Det är så vi kan skapa största möjliga effekt genom att bara bygga det som faktiskt behövs.

Och det är här skillnaden blir förvånansvärt lätt att missa. Vi kan ersätta krav med Epics och Stories, göra våra Stories små och leverera fungerande funktionalitet en Story i taget – och ändå ha bestämt på förhand vad som ska byggas.

Om en Epic är klar först när alla Stories vi definierade från början är klara arbetar vi fortfarande mot en fördefinierad lösning. Det vi lär oss längs vägen kan påverka hur vi bygger den, men inte besvara den betydligt viktigare frågan: Behöver vi överhuvudtaget bygga resten?

Det är nedbrytningsfällan: vi tror att vi gör slicing mot en önskad effekt, när vi egentligen fortfarande bryter ner en lösning som vi redan har bestämt oss för att bygga.

Den verkliga förflyttningen är inte från stora delar till små. Den är från att bryta ner en redan bestämd lösning till att steg för steg upptäcka vad som är värt att bygga.

Fler fällor

Det här är en av flera fällor i en serie: Fällor i övergången från projekt till produktteam

Se helheten

Nedbrytningsfällan i planering är ett exempel på vad som kan hända när vi förändrar vårt sätt att arbeta utan att fullt ut förändra den underliggande logiken.

Vår poster Project vs Product Organization in a Nutshell belyser den här förflyttningen ur flera perspektiv – bland annat strategi, genomförande, styrning, team, finansiering, kultur och organisation.

When we have a large amount of work, we need to break it into smaller pieces. If we know that what we have in mind will create the outcome we want, this is fairly straightforward. We can define the solution, divide it into manageable parts and implement them.

But when the outcome depends on how people behave or how a complex system responds, we cannot know the effect upfront. We can have data, experience and good reasons to believe our idea will work, but until people start using it and the system starts responding, we have a hypothesis, not an answer.

A requirement describes something we have decided to build. A Main Requirement can be broken down into System Requirements and then into increasingly detailed requirements. The pieces become more manageable, but they remain parts of a predefined whole. We build the parts, integrate them and test the complete solution. The logic is essentially: define the solution, break it down, build the parts, integrate and test.

An outcome-oriented Epic starts somewhere else. Rather than defining what to build, it defines the change we want to create. For example: Increase the share of first-time restaurant guests who return within two weeks from 18% to 35%. We know what we want to achieve, but not everything we need to build to get there.

This means we cannot simply break the Epic down into all the Stories required to complete it. We don’t yet know which Stories will be needed. Instead, we choose a small piece of user functionality that we believe could move us towards the outcome. We deliver it, see what happens and let what we learn influence what comes next.

The work becomes both incremental and iterative. Each slice adds working functionality and gives us an opportunity to learn before making the next decision.

The question is not how small the pieces are. It is what they are pieces of.

In breakdown, the pieces are parts of a solution we have already decided to build, and we may need to integrate them before we can test the complete solution. In slicing, each piece gives us something working that allows us to see whether we are moving towards the desired outcome before deciding what to build next.

Starting from an outcome also leaves more of the problem-solving with the team. Instead of receiving a solution whose important decisions have already been made, the team can use its collective expertise, together with feedback from users and the system, to decide what is worth building next.

And sometimes the most valuable thing we learn is that we don’t need everything we originally imagined.

If three Stories create enough of the desired outcome, there may be no reason to continue with Stories four through ten. They are not unfinished work. They are work we discovered we did not need to do. This is how we maximize outcome while minimizing output.

The difference can be surprisingly easy to miss. We can replace requirements with Epics and Stories, make the Stories small and deliver working functionality one Story at a time, while still deciding upfront what the complete solution should contain.

If completing all the predefined Stories means completing the Epic, we are still working towards a predefined solution. Learning may influence how we implement it, but it cannot answer the more important question: Should we build the rest of it at all?

That is The Work Breakdown Trap: we think we are slicing towards an outcome, while we are actually breaking down a solution we have already decided to build.

The real shift is not from large pieces to small pieces. It is from breaking down what we think we need to build to discovering what is worth building next.

More traps

The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.

See the bigger picture

The Work Breakdown Trap is one example of what can happen when we change the way we work without fully changing the underlying logic.

Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives — including strategy, execution, governance, teams, funding, culture and organization.

When we have learned to work in a project-based way, planning can easily become something a few people do for others. A leader or expert, perhaps together with a few others, thinks through the work, creates the plan and prepares it for others to execute.

This can feel like an efficient use of people’s time. Why involve people before their expertise is needed, or have them spend time in discussions where they may have little to contribute?

And sometimes this is exactly the right thing to do.

If we are not operating in complexity, the problem may be understood well enough, cause and effect sufficiently predictable and existing expertise enough to determine a good solution. A technical specialist may be perfectly capable of planning a technical change, just as someone with deep testing expertise may be the right person to design a particular test approach. Not every decision benefits from involving the whole team.

The trap appears when we use the same planning logic while operating in complexity.

Complexity may come from the problem itself, technology, customer behaviour, organizational dependencies, competing needs or a changing environment. In these situations, we cannot know everything we need to make good decisions upfront. Some knowledge is distributed across different people and perspectives. Some simply do not exist yet. It emerges as we interact, experiment and learn.

When people start thinking together, someone may know something about the customer that changes how others see the problem. A developer may see a simpler possibility. Someone spots an organizational dependency. A question exposes an assumption nobody realized they were making. And very often someone says: “Wait – I didn’t know that.”

This is not a failure of preparation. It is learning happening. We are not simply sharing what we already know. We are creating new understanding together.

In complexity, this makes it difficult to separate planning neatly from execution. Execution itself creates knowledge. The more detailed decisions we make upfront, the more decisions we make before that knowledge exists.

One place this becomes very visible is the backlog. Work for a long time into the future is planned ahead and sometimes even planned into sprint buckets; Sprint 1, Sprint 2, Sprint 3 and several sprints beyond. It looks very different from a traditional project plan, but the underlying logic can be surprisingly similar: a few people have decided in advance what many people will do later.

Thinking ahead is not the problem. The problem is deciding too much before the learning that could change those decisions has happened.

The Planning Efficiency Trap: Moving from project planning to sprint planning can leave the old planning logic intact — in the name of efficiency.

The answer is not to have the whole team plan everything further ahead. That would simply spend more people’s time making decisions when knowledge is at its lowest. Instead, bring the relevant perspectives together when the thinking matters, as close to execution as reasonably possible. What we learn today should be allowed to influence what we decide tomorrow.

So the useful question is not whether planning should be done alone or together. Ask instead: Can we make this decision from what we already know, or do we need to learn our way towards it?

There is a longer-term consequence too. When a few people repeatedly do the thinking and others execute their plans, the team gets fewer opportunities to understand the product, challenge assumptions and develop its own ability to navigate complexity. Planning together where learning matters is therefore not only about making better decisions now. It gradually builds the team’s ability to make better decisions without someone else having to make those decisions for them.

That is the Planning Efficiency Trap. In complexity, we may try to make planning more efficient by involving fewer people and making more decisions upfront, precisely when we have the least knowledge to make them.

More traps

The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.

See the bigger picture

The Planning efficiency trap is one example of what can happen when we change the way we work without fully changing the underlying logic.

Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives — including strategy, execution, governance, teams, funding, culture and organization.

Organizations rarely suffer from a lack of ideas. Management sees opportunities, problems and things that could be improved: new features, integrations, automations, capabilities and system changes. And when there are more ideas than we have capacity to pursue, we need to prioritize.

The question is what we prioritize.

When we are operating in complexity, the outcome may depend on how people behave, technology, organizational dependencies, competing needs or how a wider system responds. In these situations, we cannot know upfront which solution will create the effect we want. We may have data, experience and good reasons to believe an idea will work, but until we see how people and the system respond, it remains a hypothesis.

Yet it is surprisingly easy to prioritize as if we did know. Requirements, demands and solution ideas become backlog items. We may even start calling them Epics. We refine them, compare them and put them in order. The structure has changed, but the underlying question may still be the same: Which solution should we build first?

That is a reasonable question once we know what needs to be built. In complexity, however, there is an earlier question:

Which changes matter most for us to achieve now?

That small shift changes what we create direction around. A prioritized backlog of solutions gives us an order for things we might build. An outcome gives us a change to pursue.

Management will still have ideas about solutions, and those ideas can be valuable. But instead of automatically becoming future work, an idea can remain one possible way of achieving an outcome. This leaves room for the team to find a different solution, a simpler one or something much smaller that creates the same effect.

It also changes how we use the backlog. When solution ideas become future work, the backlog can gradually stretch months or even years ahead. What started as possibilities begins to look like a plan for future output.

But what we learn from what we build today should influence what we choose to build tomorrow. The more of the future we fill with predefined output, the less room we leave for future learning.

Thinking long term is not the problem. We should think far ahead about where we want to go and the changes we want to create. What we don’t need to decide far ahead is exactly what we will build to get there. A backlog can preserve ideas about the future. It doesn’t have to decide the future.

When decisions about output are made closer to the learning, we may discover that we need much less than we thought. If three Stories create enough of the desired outcome, Stories four through ten are not unfinished work. They are output we discovered we did not need.

That matters because every feature, integration and capability we add becomes something we need to maintain, support, test, secure and change. Unnecessary output costs twice: first to build, then to own.

That is the Solution Prioritization Trap: in complexity, we can become very good at prioritizing possible solutions when what we first need to prioritize is the change we want to create.

Prioritizing solutions is not the same as creating direction. Create clarity about the outcomes that matter, and decide what to build when you know enough to decide.

More traps

The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.

See the bigger picture

The solution prioritization trap is one example of what can happen when we change the way we work without fully changing the underlying logic.

Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives — including strategy, execution, governance, teams, funding, culture and organization.

Introduction

This article builds on insights from my studies in AI*, innovation, and organizational design at Halmstad University, combined with experiences from my everyday work as an Enterprise Coach at Dandy People. It has been more than a year since I completed the program, yet many of the insights have become increasingly relevant as AI has taken a more prominent place in organizations’ strategic agendas. I have reflected and found a few things that feel particularly relevant right now, especially regarding the organizational capabilities that are often overlooked when the focus shifts to the next trend or solution meant to address the challenges at hand, beyond methods and frameworks.

During the program, we worked with research on AI, decision-making, organizational structures, and innovation (product and service innovation) as part of broader systemic changes in organizations. For me, this provided new perspectives on questions I already face in my profession: how organizations are designed, how value is actually created, and why so many large and ambitious initiatives lose momentum along the way – especially regarding the organizational capabilities that are often forgotten when the focus shifts to the next trend, the next tool, or the next framework.

This article takes a clear perspective: organizational structure and design, operating models, and digitalization. Other equally important aspects—such as data security, regulatory issues (Candelon et al., 2021), or the cognitive and emotional dimensions of AI and trust (Glikson & Woolley, 2020; Huang & Rust, 2021)—require deeper exploration and may become topics for future blog posts.

AI Investments as Part of Systemic Change

AI is becoming one of the most significant organizational investments of our time. Not because the technology itself is expensive, but because it requires us to rethink how and where decisions are made, how we collaborate, and how we think about customer value.

The pattern I often see is that when organizations say they are “investing in AI,” they usually mean investments in models, platforms, tools, or external consultants who support implementation. At the same time, the structural and cultural investments required for a real transformation are underestimated.

In practice, this is closely connected to something I often observe in different client assignments: a tendency to simplify organizational challenges by searching for quick and easy solutions in technology and tools.

AI is therefore easily reduced to a question of implementing new technology or introducing a new way of working, rather than addressing the underlying structures, incentives, and behaviors that actually need to change—and which are inherently more complex in its nature.

Misguided investments can be costly for organizations, not only from legal, ethical, and business perspectives, but also in terms of employee insecurity and bias in data (van Giffen et al., 2022).

What has become increasingly clear is that AI cannot be treated as just another organizational “trend” that companies rush to adopt in order not to miss out. Just as with previous waves such as digitalization, DevOps, agile practices (particularly large-scale frameworks), and data—AI requires a shift in how organizations are designed and governed.

This is where competence in organizational design and operational transformation becomes crucial. I do not mean simply introducing a framework or scaling a method, but actually changing structures, mandates, and ways of working.

Signs that organizations struggle to build long-term capabilities include numerous initiatives, experiments, and pilots that stall, attempts to scale that lose momentum, and an organization where trust in the transformation effort gradually declines and eventually erodes altogether.

AI Reveals and Amplifies What Already Exists

In Competing in the Age of AI, Iansiti and Lakhani (2020) describe a decisive difference between companies that succeed with AI and those that do not – their core business processes are digitalized end-to-end, with minimal friction between data, decisions, and action. Without that shift, AI initiatives risk delivering limited impact and even worse, amplifying the very issues and dysfunctions that already exist. This is also highlighted in the DORA Report 2025 and its AI Capabilities Model.

Without a sufficiently strong foundation, AI will accelerate the existing culture and structures of an organization (for better and for worse). The technology itself rarely creates problems, but it makes existing patterns more visible. A few examples illustrate this:

• When AI is implemented within functions, it tends to optimize locally around specific processes without considering the broader system. The result is simply more efficient silos.
• When AI is trained on historical data, it reproduces the decisions, priorities, and structures that have shaped the organization in the past. In doing so, AI reinforces the organization’s history—its power structures, priorities, decisions, interpretations, incentives, shortcuts, and compromises. The result can lead to leadership communicating a new direction while the AI is trained on the existing setup.
• When AI generates insights faster but the organization remains stuck in structures characterized by manual handovers, reports, meetings, unclear responsibilities, unclear decision paths, and strong boundaries between organizational units, the result is better analysis but no faster execution and no increased ability to act.
• When AI is introduced in a context designed primarily for control, compliance, and reporting, the technology is also likely to be used mainly for monitoring, reporting, and optimization. In such cases, AI reinforces a “control culture,” with centralized decision-making and reduced autonomy where decisions should instead be made closer to where value is created.

Why Digital Organizations Can Scale

A recurring pitfall is that digitalization is treated as an IT- or change initiative alongside the business, rather than as part of its core operations. When this happens, the business-critical flows remain manual and fragmented. But an organization cannot be agile without a stable core. Only when the core processes are digitalized end-to-end (from the customer interaction through to internal operations) do short feedback loops, learning, and rapid adaptation become possible (Davenport & Ronanki, 2018).

Inledning

Den här texten bygger på insikter från mina studier inom AI*, innovation och organisationsdesign vid Halmstad Högskola, i kombination med erfarenheter från min vardag som Enterprise coach på Dandy People. Det har gått mer än ett år sedan utbildningen, men många av insikterna har blivit allt mer aktuella i takt med att AI tagit större plats i organisationernas strategiska arbete. Jag har landat i några reflektioner som jag upplever är särskilt relevanta just nu, inte minst kopplat till organisatoriska förmågor som glöms bort när fokus hamnar på nästa trend och lösning för att möta vår tids utmaningar, bortom metoder och fallerade ramverk.  

I utbildningen arbetade vi med aktuell forskning kring AI, beslutsfattande, organisatoriska strukturer och innovation som en del av större systemförändringar i organisationer. För mig har det gett nya infallsvinklar till frågor jag redan möter i mitt arbete: hur organisationer är designade, hur värde faktiskt skapas och varför så många stora ambitiösa initiativ tappar kraft på vägen.

 Jag har landat i några reflektioner som jag upplever är särskilt relevanta just nu, inte minst kopplat till de organisatoriska förmågor som ofta glöms bort när fokus hamnar på nästa trend, nästa verktyg eller nästa ramverk.

Den här texten tar ett tydligt perspektiv: organisationsstruktur och design, operationell modell och digitalisering. Andra minst lika viktiga aspekter som datasäkerhet, regulatoriska frågor (Candelon et al., 2021) eller till exempel de kognitiva och empatiska dimensionerna av AI och tillit (Glikson & Woolley, 2020; Huang & Rust, 2021) kräver en djupdykning för sig och kan bli en bloggpost längre fram.

AI-investeringar som en del av systemförändring

AI håller på att bli en av de mest omfattande organisatoriska investeringarna i vår tid. Inte för att tekniken i sig är dyr, utan för att den kräver att vi förändrar hur och var beslut fattas, hur vi samarbetar och hur vi tänker kring kundvärde.

Mönstret jag ser är att när organisationer säger att de ”investerar i AI” menar de ofta investeringar i modeller, plattformar, verktyg eller extern kompetens i konsulter som ska stötta implementering. Samtidigt underskattas de strukturella och kulturella investeringar som krävs för en verklig omställning.

I praktiken hänger det nära ihop med något jag ofta ser i uppdrag: en vilja att förenkla organisatoriska utmaningar genom att söka snabba och enkla lösningar i teknik och verktyg. 

AI förenklas då lätt till en fråga om implementering av ny teknik eller ett nytt arbetssätt, snarare än att ta tag i underliggande strukturer, incitament och beteenden som behöver förändras som är mer komplexa i sin karaktär. 

Fel investeringar kan kosta företaget mycket utifrån legala, etiska och affärsmässiga aspekter men också i form av otrygghet hos medarbetare och bias i data (van Giffen et al., 2022). 

Det som blivit allt tydligare är att AI inte kan behandlas som ännu en organisatorisk ”trend” man stressat hoppar på för att inte missa tåget. Precis som vid tidigare vågor, exempelvis digitalisering, DevOps, agilt (läs storskaliga ramverk) och Data kräver AI en omställning av hur organisationen är designad och hur den styrs. 

Det är här kompetens inom organisationsdesign och operativ omställning blir avgörande. Jag avser inte att man enbart inför ett ramverk eller skala en metod, utan att faktiskt förändra strukturer, mandat och arbetssätt.

Tecken på att man inte lyckas bygga förmågor långsiktigt är många påbörjade initiativ, experiment och piloter som stannat av, försök till att skala som tappar fart och en organisation där tilltron till förändringsarbetet gradvis sjunker och till slut urholkas helt.

AI synliggör och förstärker det som redan finns

I Competing in the Age of AI beskriver Iansiti & Lakhani (2020) det som skiljer företag som lyckas med AI på en avgörande punkt: deras kärnverksamhet är digitaliserad** end-to-end, med minimala hinder mellan data, beslut och handling. 

Utan den förflyttningen riskerar AI-satsningar att ge begränsad effekt och ännu värre förvärra det som redan skaver, vilket även lyfts i DORA report 2025: AI capabilities model.

Utan en tillräckligt bra grund kommer AI accelerera befintlig kultur och struktur på gott och ont. Tekniken skapar sällan problem i sig, men nu synliggörs redan existerande mönster. Några exempel:

• När AI implementeras i enskilda funktioner tränas den att optimera lokalt kring till exempel processer utan hänsyn till helheten. Resultatet blir kort och gott, endast effektivare silos. 
• När AI tillämpas på historiska data återskapar den de beslut, prioriteringar och strukturer som redan präglat organisationen. AI förstärker då organisationens historia baserad på exempelvis maktstrukturer, prioriteringar, beslut, tolkningar, belöningar, genvägar och kompromisser. Resultatet kan bli att ledningen kommunicerar en ny riktning medan AI tränas på det befintliga.
• När AI tar fram insikter snabbare men organisationen fortfarande sitter fast i strukturer med manuella överlämningar, rapporter, möten, otydligt ansvar och otydliga beslutsvägar samt vattentäta skott mellan organisationens delar så blir resultatet enbart bättre analyser men inget snabbare genomförande eller mer handlingskraft.  
• När AI introduceras i en kontext som är uppsatt för kontroll, uppföljning och efterlevnad så tenderar man också att använda tekniken för rapportering, övervakning och optimering. AI förstärker då “kontrollkulturen” med centraliserade beslut och minskat mandat (låg autonomi) där beslut bör fattas i organisationen.

Varför digitala organisationer kan växa

En återkommande fallgrop är att digitalisering hanteras som ett IT- eller förändringsinitiativ vid sidan av verksamheten. Då kommer de affärskritiska flödena fortsätta att vara manuella och uppdelade. Men en organisation kan inte vara agil utan en stabil grund. Först när flödena är digitaliserade från kundens interaktion till den interna verksamheten, så möjliggörs korta feedbackloopar, lärande och snabb anpassning (Davenport & Ronanki, 2018).

Det här är exakt den poäng Iansiti & Lakhani gör (se bild ovan). I traditionella operationella modeller ger tillväxt (skala) värde upp till en viss punkt. I takt med ökad användning och fler kunder vid en given punkt ökar komplexiteten snabbare än värdet man får ut, vilket innebär att effekten planar ut. Det innebär snabbt fler lager, mer administration och samordning som i sin tur leder till ökade kostnader och pressade marginaler. 

I en digital operationell modell minskar däremot friktionen mellan data/insikt och effekt. Det gör att värdekurvan inte planar ut på samma sätt när organisationen växer.

Man kan se det som en operativ hävstång där nya kunder förbättrar systemet. Ju mer tjänsten eller produkten används, genereras mer data och bättre insikter vilket i sin tur höjer kvaliteten i prioriteringar och beslut. Det liknar det som inom Product growth kallas en growth loop där ökad användning skapar mervärde som driver ytterligare användning vilket minskar behovet av en traditionell säljorganisation. 

Men den dynamiken uppstår inte av sig själv. Den förutsätter en operativ modell som faktiskt kan fånga upp lärande, omsätta data och justera riktning i takt med att systemet utvecklas. Det är här begreppet scalable learning (eller skalbart lärande som jag valt att direktöversätta begreppet till) kommer in i bilden.

Skalbart lärande som en del av den dagliga driften

Traditionellt lär sig organisationer långsamt genom att man lanserar något, samlar feedback, analyserar, planerar och implementerar i nästa leveranscykel. AI förändrar det här genom att kontinuerligt analysera exempelvis ändrade kundbeteenden, se mönster i realtid, generera insikter utan manuell inblandning och även föreslå förbättringar. Oavsett om det exempelvis är en digital produkt, fysisk produkt inom industrin eller ett koncept inom FMCG, så är principen densamma, vart uppstår lärandet och hur snabb kan feedbackloopen bli. Skillnaden är att lärandet inte alltid sitter i produkten utan i produktion, distribution eller marknad. Problemet är att den här förflyttningen inte händer av sig självt.

Nästan alla organisationer jag mött genom åren fastnar just här oavsett trend, verktyg eller metod som investeringen gjorts i. Vi brukar prata om dubbel byråkrati vilket innebär att man introducerar och lägger på “det nya” i systemet utan att justera, förenkla och ta bort det gamla. AI läggs då ovanpå befintliga strukturer och processer, medan den operationella modellen i grunden fortfarande är designad för stabilitet, silos och förutsägbarhet snarare än för kontinuerligt lärande.

När grunden inte förändrats försöker man istället skapa förändring (med god intention) genom mer struktur. Under de senaste tio åren har många organisationer försökt skala genom ramverk. Här tenderar ramverket i stället öka graden av koordinering genom fler lager av planering, nya forum och roller samt team, men de förändrar inte automatiskt den underliggande logiken. Resultatet blir ofta mer struktur där en agilitet är svår att uppnå. 

Om kärnprocesserna fortfarande är uppdelade och beroende av manuella överlämningar riskerar man att i stället skala omfattande kostnader för samordning och koordinering snarare än lärande. Digitala operativa modellers skalbarhet handlar därför inte i första hand om fler lager av styrning. Den handlar om att minska friktionen i det verksamhetskritiska flödet så att man snabbare kan omsätta insikterna till att optimera sina produkter och tjänster.

Konsekvensen, enligt flera av de studier jag tagit del av, är att många organisationer väljer att introducera AI genom omfattande initiativ i form av projekt eller program. Initiativ som får egna mål, budgetar och leveranser. Istället för att successivt bygga förmågor i det dagliga operationella arbetet etableras AI som en parallell sidoverksamheten, snarare än en integrerad del av hur värde skapas över tid.

Ett genomgående budskap i forskningen är snarare att AI-mognad utvecklas bäst genom kontinuerliga iterationer och inte genom isolerade program. De stora, ambitiösa AI-programmen riskerar att skapa långa startsträckor och höga förväntningar, utan att organisationen samtidigt utvecklar sin förmåga att lära (Iansiti & Lakhani, 2020; Wilson et al., 2018). 

Men för att arbeta iterativt med AI räcker det inte att förändra arbetssättet, även strukturen måste möjliggöra rörelse över funktionsgränser och silos. Här blir agilitet avgörande.

Organisationsdesign som möjliggörare

Forskning visar att AI och data har potential att bryta organisatoriska silos genom att skapa en gemensam helhetsbild av kundbeteenden, marknadsdynamik och operativ prestation (Shrestha et al., 2019). 

Men en gemensam helhetsbild räcker inte i sig. Om varje funktion fortsätter att optimera utifrån sitt eget perspektiv och gör ännu mer avancerad analys så skulle det inte förändra något i praktiken så länge trögheten mellan funktionerna finns kvar. 

Det är alltså inte AI-tekniken som gör jobbet. AI och data kan synliggöra helheten, men utan rörlighet och dynamik mellan funktioner kan organisationen inte agera på insikter.  

För att kunna agera på en gemensam förståelse krävs tvärfunktionella, produktorienterade team som delar effektmål och har mandat att ta ansvar för hela kundupplevelsen. Det här driver samarbete, det blir enklare och beslut kan fattas utifrån samlade bearbetade insikter. 

I merparten av de organisationer vi på Dandy People stöttar, lever silobaserade funktioner vidare, trots omfattande agila satsningar. Styrning, budgetlogik och ansvar är fortfarande funktionellt organiserat. I den kontexten kan inte AI användas för en mer dynamisk styrning, utan utgör enbart avrapportering och beslutsstöd långt från där värdet skapas nära produktteam. 

Agilitet i en kontext med AI handlar därför mindre om metoder och mer om hur en organisation designas för att skapa en förmåga där man snabbt kan omsätta insikter och justera riktning i takt med lärande.

Summering

• AI är vår tids nästa tekniksprång. Men till skillnad från många tidigare trender går det inte att isolera till enbart teknik, metoder eller verktyg. 
• AI förstärker den organisation och dess kultur som redan finns, både det som fungerar och det som redan skaver. Därför blir bristerna plötsligt synliga.
• Vill vi få ut riktig effekt av våra investeringar i AI räcker det inte med nya modeller, plattformar eller program. Det kräver att man digitaliserar sina kärnflöden, ser över styrning och mandat och bygger en förmåga att lära i vardagen.
• AI är katalysator på gott och ont. Resultatet avgörs av hur vi har valt att designa organisationen, vilken operationell modell och förändringsledning i förflyttningen för att få ut effekt av investeringar.
• Att ta in kompetensen för att bygga organisatorisk förmåga och en stabil grund är väl värt att investera i.

Referenser

• DORA (2025).
  DORA AI Capabilities Model (report).
• Candelon, F., Reichert, T., Duranton, S., Di Carlo, M., & Sigurdsson, E. (2021).
  AI regulation is coming. Boston Consulting Group.
• Davenport, T. H., & Ronanki, R. (2018).
  Artificial intelligence for the real world. Harvard Business Review.
• Glikson, E., & Woolley, A. W. (2020).
  Human trust in artificial intelligence: Review of empirical research. Academy of Management Annals.
• Huang, M.-H., & Rust, R. T. (2021).
  A strategic framework for artificial intelligence in marketing. Journal of the Academy of Marketing Science.
• Iansiti, M., & Lakhani, K. R. (2020).
  Competing in the Age of AI: Strategy and Leadership When Algorithms and Networks Run the World. Harvard Business Review Press.
• Shrestha, Y. R., Ben-Menahem, S. M., & von Krogh, G. (2019).
  Organizational decision-making structures in the age of artificial intelligence. California Management Review.
• van Giffen, B., Herhausen, D., & Fahse, T. (2022).
  Overcoming the pitfalls of algorithms: A classification of machine learning biases and mitigation methods. Journal of Business Research.
• Wilson, H. J., & Daugherty, P. R. (2018).
  Collaborative intelligence: Humans and AI are joining forces. Harvard Business Review.

Konflikter eller oenigheter är vanliga i det dagliga livet. Det är ofta en kombination av två eller fler typer av konflikter. Var därför säker på att identifiera vilka typer av konflikter det handlar om och om möjligt, välj fler lösningsansatser.

Den här postern är framtagen tillsammans med Björn Sandberg.

Den här postern går igenom 5 typer av konflikter

• Intressekonflikt
• Maktkonflikt
• Mognadskonflikt
• Värderingskonflikt
• Missuppfattningskonflikt

Den visar också på 5 typer av lösningar

• Samarbeta
• Kompromissa
• Justera
• Undvika
• Kämpa eller tvinga

Välkommen att ladda ner den här postern i högupplöst PDF >

Maktkonflikt

Makt och auktoritet är det som de flesta tänker är grunden till alla konflikter. Maktkonflikter känner de flesta av oss igen från arbete och familj, där frågan handlar om vem som ska bestämma. Viljan att bestämma kommer tidigt, när barn vill ha kontroll över situationen – till exempel vilka kläder de ska ha på sig – för att få personlig makt och självkänsla.

Den negativa sidan av maktkonflikter kan vara så allvarlig som övergrepp eller missbruk. Det möjliga hotet om att förlora makt kan också vara en källa till konflikt i agila transformationer, när mandatet flyttas ut i teamen och kompetensen delas med andra i gruppen.

Intressekonflikt

Den vanligaste typen av konflikt uppstår när två eller fler parter har olika perspektiv, behov eller mål som de värnar om och kämpar för att uppnå. Ett exempel är när förändring införs i en organisation och människor möts för att argumentera för sina ståndpunkter och försöka övertyga andra om att deras synsätt är det rätta. Om de inte kan nå en kompromiss eller en vinn-vinn-lösning, är det tillgången till makt och mandat som avgör vem som vinner eller förlorar.

Auf diesem Poster habe ich einige Organisationsdesign-Muster aus agilen Produktorganisationen im großen Maßstab gesammelt.
Die hervorgehobenen Fragen können als Einstieg in verschiedene Themen dienen – etwa zu den Gestaltungsprinzipien der Organisation, zur Strategie für das Wachstum von Teams und Einzelpersonen, dazu, wie Autonomie und Ausrichtung ermöglicht werden können, und wie Führungsteams gestaltet werden können, um eine großartige Produktorganisation zu unterstützen und weiterzuentwickeln, die Produkte liefert, die Kundinnen und Kunden lieben.

Dieses Poster wurde ins Deutsche übersetzt von Andre Ullmann, kontakt@andreullmann.de

Download the German poster for free (high resolution PDF) >

Buy printed in size A1 >

Hervorgehobene Fragen zur Reflexion auf diesem Poster

• Wie messen wir Erfolg?
• Was sind unsere Leitprinzipien?
• Optimieren wir für Fluss (Flow)?
• Optimieren wir für Wert (Value)?
• Welche Fähigkeiten müssen wir skalieren?
• Wie ermöglichen wir den Informationsfluss?
• Was ist die minimale wertvolle Bürokratie (Minimum Valuable Bureaucracy)?
• Welche Rollen benötigen wir in unserem Führungsteam?
• Wie fördern wir das Wachstum von Teams und Einzelpersonen?
• Welche Arten von Teams brauchen wir?
• Wie ermöglichen wir sowohl Autonomie als auch Ausrichtung?
  
  

Really grateful for the invitation to give a closing keynote at Agila Sverige on the topic of Product-Led, among so many other amazing speakers.

I also enjoyed being part of the panel on the Product Operating Model together with Mikael Brodd and Jimmy Janlén.

I felt truly welcomed, had a lot of fun, learned something new, and left feeling energized. 🙂

A huge thank you to all of you in pink t-shirts 👚 for once again creating such a safe, fun, loving, innovative, thoughtful, and thought-provoking community. You rock! 🙌

Hope to see you all again next year!

Thank you Isabelle Svärd and Jimmy for the pics 📸

Många personer idag upplever att deras PM sitter väldigt isolerad och inte samarbetar tillräckligt. Tex. sales som får mycket information om vad kunder vill ha och inte vill ha, men upplever att de inte har någonstans att informera vidare och upplever i alla fall många gånger inte att PM engagerar sig i att efterfråga feedbacken. Eller så händer inget utifrån att PM fått den.

Det finns många olika exempel, men vi ska stanna här. Vi ska istället gå in på vad det här beror på? Vad är det som gör att de inte samarbetar och blir isolerade öar?

Sommaren – en tid de flesta av oss längtar efter och har så stora förhoppningar på. Vi ska läsa den där boken som legat länge och vi inte hunnit läsa, umgås med alla våra vänner vi sett så lite av, resa till platser vi vill se, bada i ett varmt hav, mysa med familjen, få sol på kroppen och ladda D-vitamin, komma igång med träningen, måla färdigt huset, äta sunt…. ja det blir lätt väldigt mycket!

Förhoppningarna och verkligheten

Mina förhoppningar för sommarsemestern var att få vara nära min man och naturen, lapa D-vitamin i solen och få uppleva magisk natur. Enkelhet, det var min prioritering. Jag ville också gärna umgås med mina vuxna barn och vänner. Som för så många andra så blev det, så här långt, en mix av det jag önskade och sådant jag inte önskat. Vilket det vanligen blir i slutändan. Men, jag valde att se min semester som den perfekta sommarmixen.

Om livet är perfekt eller inte handlar mycket om vår inställning till livet och det som sker. Vi kan inte få allt vi vill, och vad vore tjusningen i det om vi hela tiden kunde få allt vi önskar? De saker jag fick var värdefulla för mig och jag uppskattar dem enormt mycket. De har gett mig energi, tacksamhet, insikter och glädje. De saker jag inte önskade mig men som skedde ändå, har förhoppningsvis lärt mig något.