A naukri.com initiative
The Beautiful Mess
3w
176
Image Credit: The Beautiful Mess
TBM 336: Product OS Design Tips and Principles
- Product leaders operate under a product operating system that is implicit in some companies but explicitly designed in others. It involves a dynamic mix of leadership, service design, organizational design, systems thinking, human factors, behaviour design, cultural anthropology, communication design, organizational development, and (even some) game design.
- The product operating system is a designed product platform that includes multi-sided marketplaces that cater to customers, leaders, managers and front-line teams. Success breeds new challenges, so companies must continue to adapt, experiment and solicit feedback to ensure everyone’s alignment.
- Senior leaders should own the operating system. They should be curious about the product operating system and start with rituals that consist of who should interact with whom, how often and toward what end, stating insights, context, tools needed and shared artefacts to make the operation seamless.
- While developing processes, do not take into account every single exception. If you try to cover every specific exception, the stringency of processes becomes too heavy. Design processes to solve problems on the fly, and consider adding clarity and structure to norm exceptions if they happen often enough.
- IKEA effect is real, so teams prefer to be included in designing a solution. Ensure you mix well-trodden approaches with unique twists to avoid making it hard for newcomers to connect.
- Think in terms of consistent interfaces, not consistent processes. Different teams use different approaches, but as long as there is reasonable consistency in other forms of interaction, it should be fine.
- Every team has stubbornness quotas, but do not exceed them. While some teams are stubborn about a certain approach, be open to adjusting if the present approach is no longer effective. Great teams highlight transparency but don’t feed on lone areas of stubbornness that could divide the team.
- Do not rely on templates so much that the real deal is lost. Thinking is more valuable, so encourage everyone to provide their ideas. Create an example repository where you can highlight how different groups achieved the same desired result.
- Making the system work and establishing a habit is like a personal habit, it takes time to stick. It’s important to foster conditions where people can see their job’s value, borrow habits from others and are open to feedback while not feeling underestimated.
- Ensure that the product operating system encourages experimentation, ignores false precision and enhances goal-setting without being over-bureaucratic while enabling constraints and limiting constraints produced some desired outcome and the decisions are made visible.
- Understand that operating systems are a set of constraints. Some are limiting while others are enabling. Enabling constraints provide your team with better situations while limiting constraints make working conditions more challenging.
- Beware of the dependency inflection point. When a company exceeds the dependency tipping point, there’s a need to support new collaboration patterns or suppress dependencies.
- Scaffolds are temporary and should provide structural support when things go wrong. Remove scaffolds once the problems are resolved to avoid normalizing informal communication processes.
- Strike a balance between insiders and newcomers because insiders tend to be habitual and risk-averse while newcomers know nothing about the current processes and need more time to adapt. Endless forms completed by front-line teams lead to reports without bearing reality. They need to know how decision-making is based on the information they fill in.
- Match cycle length to rate of change in market conditions. Focus on the essential work and have a well-formed strategy that evokes coherence sliding to action. Avoid cascading goals that rely on org charts; rather, have relative stable inputs and set goals based on the input.
- Conduct retrospective evaluations on the full history of an effort to better understand the players involved, how they collaborated and what they achieved. Avoid resting goals or strategies on cascading plans that follow org charts which cause work to be too prescriptive.
Read Full Article
10 Likes
For uninterrupted reading, download the app