|
How Structuring Adaptable & Integrated Product Teams Generates Success In Organizations Large & Small.
“Top-down, command-and-control organizations with billions of dollars and thousands of employees are getting their butts kicked by small, agile teams with only a handful of employees, informal org structures and very little resources.” Although the media loves to present this story, this isn’t actually what’s happening. The reality is more complicated. Some large companies, with their associated scale and bureaucracy are doing pretty well, while many small companies with all their nimbleness and flexibility are struggling to stay alive. So what’s better, big and robust or small and adaptive? The answer is both. An Inauspicious StartTo understand how the modern product teams are delivering value to their companies and customers, we need to take a look at the sometimes distasteful evolution of the product organization. By the end of the 1800’s the business world was frothing in excitement over the scientific management promises of Taylorism. Suddenly the randomness of hand-crafting products was replaced by a predictable approach. Factories full of “mentally sluggish” workers could start making things with greater scale, frequency and precision. “I have you for your strength and mechanical ability. We have other men paid for thinking” Frederick W. Taylor (Image source: Mockingbird) Taylor’s mocking attitude and reductionism brought control and planned outputs to the previous era of unpredictable quality and unreliable delivery. These improvements in efficiency came at the cost of individual creativity and respect for the worker. In Taylor’s world, managers did the “thinking” while factory floor or typing pool workers kept their mouths shut and performed their mundane tasks. Sadly, this approach still persists in some industries, and certainly in many developing parts of the world. We don’t need research to tell us it’s a great way to piss people off and simultaneously create myopic, inflexible businesses. Employees hate these human factory environments and customers dislike the companies that create them. Worlds CollideSlowly leaders started to discover the drawbacks to taking away the worker’s ability to make decisions on the spot. Command-and-control often meant long delays in production-line halting decisions and the poor execution of instructions as information got tangled up in the back-and-forth bureaucracy. This was never more apparent than in the military. Where structure and discipline had initially brought fractured tribal groups together to create unstoppable armies, this rigid command structure became its own worst enemy. Generals, lacking knowledge and insight from the frontlines, made poor decisions on behalf of the men on the ground. Soldiers paid the ultimate price for this top-down insanity. Probably the best statistical graphic ever drawn, this map by Charles Joseph Minard portrays the losses suffered by Napoleon’s army in the Russian campaign of 1812. (Source Edward Tufte) More agility was required. In the theatre of war the small autonomous fighting team was emerging. Although Britain’s secret sabotage teams were not the first guerrilla fighting force to exist, even Churchill, a lifelong bureaucrat, conceded to the ability of these small teams to turn the tide of WWII. These agile teams achieved outcomes that the brute force of the armies, air forces and navies were incapable of. What was considered ungentlemanly at the time is now standard operating procedure in all modern military forces. Here’s where it gets messy. When only viewed from a historical perspective, it looks like we have two conflicting models of organization: Command-and-control vs. Autonomous teams. But as with all things, this categorization leaves out the 50 shades of grey. Strengths Of TeamsIf you’ve ever watched a world class team play sport it’s obvious that although each team member has specific skills, nothing is achieved without the collaboration of everyone. Once play begins, teams don’t need to constantly watch the coach for instructions. Their actions are quick and decisive. They have a shared goal, they are practiced, but they operate autonomously. This is the primary strength of a team: autonomy. Decisions get made on the field, not in a boardroom. Individual skills networked into a cross-functional group can yield delightfully fast results. In many cases, this networked arrangement of teams makes it easy to replace lost members or continue without any supervision. The advantages of field-level decision making was beautifully demonstrated by the emergence of Lean manufacturing and the Agile development principles. But teams can lose their way more easily than command-and-control organizations. Even the mythical Silicon Valley startup with an embarrassment of funding, talent and support gets lost when they don’t have a real pain to solve or a meaningful reason to exist. Strengths Of Command StructuresWithout doubt, any group that’s pursuing a goal does better when it has a purpose. A meaningful North Star to guide their actions provides a lens for organizations to align their behavior. Any company, big or small, can create a mission, but as they grow to significant size, it becomes increasingly difficult to maintain alignment. Command structures provide institutionalized alignment to their missions. Bureaucracy has value. Not in the mind-numbing paperwork or adherence to pointless rules, but in the optimization of resources, lines of accountability, and long-term capital considerations like talent development and infrastructure investments. Unfortunately, bureaucracy often loses touch with its raison d’etre. As the scaling organization divides itself into departments and product divisions the company mission can get diluted. This dilution results in more policies, more rules and less flexibility. A vicious circle indeed. Bureaucrats often become a self-perpetuating institution enforcing policy over purpose. One part of the solution to avoiding death by bureaucracy is the creation of a product vision and product strategy for each product group. This reinforces a relevant product-level North Star, while still taking advantage of the corporate benefits of resource allocations, long-term strategic planning and senior level support. Hybrid ModelReality has a habit of making fools out of theorists. While it might be easier to latch onto a single model, the messy truth is that organizations are essentially combinations of different approaches. Like the recombination of parental genes, organizations are a blend of inherited characteristics. Outside of economics class, all companies are imperfectly blended models. The fast scaling business has problems that the startup just doesn’t have. Amazon announced last year it’ll hire 50,000 new employees. Demands like this are an inconceivable challenge for new companies. While Amazon might preserve the zeitgeist of a startup with it’s two-pizza meeting rule and Day One Principle, it needs some control over the massive organization it has become. When companies promise customer value that’s reliant on complex logistical, financial and administrative systems, a little control goes a long way. Enter the hybrid model. Perfectly ImperfectWhen I interview veteran product leaders they always embrace the ambiguity of evolving businesses. Unlike the business student bent on a perfect model, seasoned leaders know that the Franken-org is a little closer to reality. In contrast to the monster metaphor, a modern product organization hybrid doesn’t need to look or act like something that you built in your garage. Chris Fussell, author of One Mission and coauthor of Team of Teams, describes the benefits of the hybrid, “You can’t throw away what works in a bureaucracy — optimization of assets, accountability, long- term planning and development of talent, certain linear decision-making processes.” The command model provides much needed air support, while “Teams and small units, by contrast, are unmatched for their spirit and agility of performance; also their ability to make non-linear decisions and innovate on the fly” says Fussell. Given that bureaucracies can be rigid and risk-averse they need to be infused with the agility of teams. Simultaneously teams need to ensure they don’t end up in a bubble of their own team culture, a lack of empathy or a failure to communicate with other teams. How Does This Work For Your Company?The approaches below are not linear. They are intended to be parts of a larger effort to make your product organization more adaptable and flexible. However, they could certainly be used independently. 1. Create a Product Vision, Product Strategy and PrioritiesFor the scaling company a single company mission is necessary but insufficient. They will also need to create a Product Vision, Product Strategy and Priorities for each product that it supports. A Product Vision is also necessary but insufficient, and thus requires a full capabilities and sustainability exploration. Developing a Product Vision that is both connected to the company mission above it and connected to the strategy and priorities below it will create more alignment vertically and horizontally across your organization. This approach benefits from the top-down focus of a command model, while preserving the autonomy of the product team. Alignment also leads to better decision making, which creates velocity. 2. Communicate, Communicate & CommunicateIt cannot be overstated how important it is that the Mission, Product Vision(s) and Product Strategy be communicated at every opportunity. Communicate every single day. Until you hear your team repeating these things back to you without prompting, or observe it in their daily actions, you have not made an impression. The first step in communication is to have your story straight. A clear, motivating narrative needs to back up all of your conversations and actions. Walk the talk. Whether you’re presenting to the entire company or to a subgroup of your team, narratives are essential. Nate Walkingshaw, Martin Eriksson and I wrote a few chapters about this topic in our Product Leadership book so I’ll refrain from regurgitating it all here. Specific tactics for communicating on a daily, weekly and intraday basis can be found in this detailed description by Nate Walkingshaw. 3. Network The NetworkIn his book of the same name, Stanley McChrystal refers to this as the Team of Teams, but as he writes it’s more than just teams. A team is just part of a network, and in order for it to continue to be valuable, it needs to be both connected to other teams and to the mothership. Networking teams require bold moves from leaders. Apart from ensuring consistent communication of the Mission, Product Vision and Strategy, it’s essential that teams be connected to each other. This can be done formally and informally, either way, it can’t be left to chance. Formally, you may choose to have team members from different product teams meet regularly to share insights, exchange ideas and learn from each other’s mistakes. For example, a product designer would meet weekly with other product designers from other teams to discuss each other's work. At first product teams might feel like this sharing is like giving away some of their competitive advantages, but over time this will be replaced with “Oh wow! That’s helpful” moments. Informally, teams that spend time with each other will relate to each other better. For a lot of people, strangers are the enemy. Encouraging simple interactions like eating lunch together, seating team members at the same table, inviting other teams to join your meetings, and demo days, are just some ideas that bond people together. It’s important to start with trust. In spite of rumors to the contrary, transparency of knowledge gives everyone insights that raise the tide for all boats. In a competition designed to solicit solutions to the Prisoner’s Dilemma, the winning entry was a simple four-line code that always began with cooperation. The program by Prof Rapoport would also never hold a grudge so that even when an opponent didn’t cooperate, the program would re-engage the moment the opponent started to cooperate. Cooperation drives networks to grow stronger. Biological systems are the same. Neural networks that fire together, wire together. The more a neuron is used in a neural loop, the more likely it is to build permanent connections to the neurons around it and increase the fluidity of that loop. 4. Structure As StrategyAt Pluralsight, a company now famous for its autonomous, cross-functional Product Experience Teams, managers deliberately connect team members to each other in daily and weekly sessions, and in real-time across a range of tools and technologies. The creation of PXTs and the environment that nurtures them allows the teams to focus almost all of the time on “the experience of the product”. This should always be the team-level priority — the customer’s experience. Product Managers, unbound from supervising teams, can then focus on networking their insights and knowledge with the rest of the organizations. In Nate Walkingshaw’s words, “this is organizing, communicating, and collaborating with different parts of the organization to inform them on what’s happening when”. To be clear, networking your teams is not something you can achieve with process management. Methodology, values and principles guide the human transactions within a network but the network itself is grown through active nurturing. The failed promises of Agile and Lean to drive speed and focus in our organizations reminds us that process means nothing when the structure is not there to support it. Structure is strategy. Process is important, but it is not a substitute for structuring your organization for better knowledge sharing, understanding and communication. These cross-functional, diverse and autonomous teams are the building blocks of the modern product organization, but they are just a part of it. Spinning up these PXTs won’t magically reshape your destiny. Leaders need to also provide these teams with space to experiment, psychological safety and to allow them to possibly fail for them to develop confidence. Like a toddler learning to walk, parents can’t hold their hands forever. 5. Educate Don’t TrainWhen building the type of hybrid teams and environment we’ve discussed here, you’re going to meet with resistance. These changes are not easy. The bureaucrats will throw the book at you and the autonomous teams will cry “live free or die”. Both will need time to see the value of this hybrid approach. An education is what’s required. But not the condescending training organizations force their workers through whenever there’s a “restructuring”. Personalized, thoughtful education that begins with having team members spend time with their colleagues in other departments and divisions. Embedding people builds empathy and connections. Connections create networks. Networks create speed. Education happens when you experience something yourself and then pass on that knowledge to others. Like the surgeon’s motto, “Watch one, do one, teach one”, having team members cross pollinate and then return to their teams to share what they have learned builds understanding and respect. Until you can publicly explain someone else’s work and their value to the organization, you don’t understand it. Final ThoughtsWhen product teams are structured so they can easily share information between the members, and the members of other teams, they get faster at making decisions. Better decisions are possible when there is a lens. Your mission, vision, values and priorities are that lens. Faster decisions equals more velocity. Add to this a deliberate interconnectedness of teams to the corporate support structures and now you have the resources needed to accelerate innovations, on-the-ground decisions and responses to a fast changing market. The leader’s role in all of this is to create a nurturing environment for these structures and behaviors to exist — and then stay out of the way! A leader will be judged by what happens when they are not in the room. too much oversight or over-the-shoulder supervision will reverse the trust these things aim to create. As a friend once reminded me, “Trust is like a glass, once broken, it’s almost impossible to repair”. Good luck, and please share your experiences, insights or alternatives with me. Richard.
0 Comments
What Is Keeping Product Teams Awake at Night?What gets done first? How do you decide what features or experiences stay and what gets cut or postponed? Should I listen to customers or my boss? How does the product team get consensus on which direction to follow? Should they even need to get consensus? If the product manager doesn’t always have the final say or authority to make that decision, then what?
These are some of the most frequently discussed questions in product teams today. This article attempts to answer these questions and provide a process for decision making and prioritization. In a survey, Mind the Product and Christian Bonilla, Product Manager and Founder of UserMuse, asked product managers and leaders to name the biggest challenges facing them. The results indicated that prioritizing roadmapping decisions without market research was by far the biggest, followed by being stretched too thin, dealing with executives, hiring and developing talent, and aligning strategy. In the Mind the Product survey, 49% of product managers said their foremost challenge is being able to conduct proper market research to validate whether the market truly needs what they’re building. In other words, what are we going to build next? When we add the responses from enterprise software PMs, this figure jumps up to 62%. Two thirds of enterprise product leaders are currently worrying about which projects are needed. Extrapolating from this, an enterprise product leader will have to dedicate the necessary amount of their time prioritizing and communicating to others about the next product release. That’s a lot of tough conversations with a lot of people. Prioritization is Personal The difficulty of prioritization is that processes involve people. People are fundamentally complex. It’s what makes us uniquely interesting. Complexity brings diversity of backgrounds and ideas to the table. But that diversity also brings challenges. We all show up with different perspectives, expectations and biases. Leading a team of people with differing ideas is both a requirement of success and the greatest challenge facing leaders. If we all see the world through different lenses, it’s not surprising that prioritizing features rates high among the challenges faced by product leaders. Any product manager knows that the most difficult part of her job is determining which things deserve the team’s time, money, and energy. These are not just unattached ideas, they are reflective of a team's personal hard work. Rejecting, postponing or ignoring someone’s idea or request can sometimes feel like the very person is being rejected. It is not just the team that can bump the prioritization off course with subjective views. In any organization, a wide range of stakeholders also need to be considered or informed. Often in senior positions, these people hold the ability to insert their choices or opinions without the necessary data or understanding. In many cases, senior opinion’s, while shared with positive motivations, have no consequences for those leaders. One derogatory term for these people is HiPPO — Highest Paid Person’s Opinion. As common as this term is, it doesn’t really give these unfortunate situations the context they deserve. Senior people are rarely malicious and referring to them as thoughtless animals only reinforces the stereotype. If anything they are probably trying to help by adding their opinions. After all, we have senior roles to represent experience in decision making. There are two ways to avoid subjectivity in prioritization. The first is to always start with the highest available source of truth. Generally this is a combination of company or product vision, go-to-market strategy, and the principles agreed to as a team or company. More about this in the next section. Martin Eriksson’s Decision Stack is a great framework for helping teams develop the skills to assess whether their activities are aligned with the vision, strategy and principles or values of the business. The second way is to understand individuals motivations and incentives. If your leadership is incentivized to move in one direction and the product team is incentivized to do something else, there will be a conflict. Resolving that conflict through direct communication with leaders before you start prioritizing is necessary. Empathizing with leaders or senior decision makers is part of good discovery. In the same way that high-performing teams invest time in understanding their customers, great teams will spend time understanding their stakeholder’s motivations. By understanding what your leaders are being held accountable for, and what their incentives are, finding support will be easier. Aligning the prioritization with company initiatives, and ensuring the senior leaders can see how that alignment will play out in the roadmap is a key consideration for getting support. Connecting Vision To Practice What not to prioritize is as important as what you’ll be prioritizing. Mina Radhakrishnan, the first Head of Product at Uber says, “a big part of product leadership is thinking about why are we doing this-and-that to set the basis for saying no, we shouldn’t do that.” If something doesn’t make sense in the context of your larger strategy then consider shelving it for another time. The vision also serves as a filter to de-prioritize the things that won’t make a meaningful difference to the value of the product or experience. Linking the product vision to the practical work can feel unnecessary when you’re trying to meet a shipping deadline. In reality, making this connection makes the work easier to understand, and can save time in the long run. For leaders and managers, reminding the team why you’re building that feature or making that improvement gives the work meaning. Seeing the connection between a task and the purpose behind it can also be motivating. Dealing with Out-of-Nowhere Requests The reality is that stakeholders clouding decisions can derail even the most well thought-out plans. Nobody likes it when high-level ideas are added to the roadmap as must-haves, especially when they are not backed up with evidence. “The team just experienced another executive swoop and poop,” says Jared Spool, Founder of UIE and CoFounder of CenterCentre, likening these executive decisions to a seagull attack. “The executive swoops into the project and poops all over the team’s design flying away as fast as they came, they leave carnage and rubble in their wake.” As humorous as this sounds it’s also way too common to dismiss as a joke. Teams and their leaders are more often working towards common goals and have no desire for anything ending in the aforementioned carnage and rubble. The absence of evidence is addressable without drama. To many product professionals, having their roadmap hijacked from time to time by other pressing issues is an unavoidable situation that must be tolerated. Tom Greever, author of Articulating Design Decisions, calls these hijacking decisions the CEO Button. “An unusual or otherwise unexpected request from an executive to add a feature that completely destroys the balance of a project and undermines the very purpose of a designer’s existence.” We acknowledge that these situations can often be harmless but if these interruptions continue unchecked they will ultimately derail the product. Fortunately there is a solution, but it is not a quick fix. Establishing Proof Points One way to avoid future disappointment, is to create a testable prototype of the idea, feature or interaction that is being planned. This can be done for most design features and interactions and currently, the easiest way to do this is with Design Sprint or Directed Discovery. Both these approaches are based on the scientific method of developing a testable hypothesis and then running the appropriate testing cycles to generate results, providing immediate evidence either for or against the hypothesis. “When the team invites real users to try a prototype, they’re collecting data about the users’ needs, which provides a solid footing for the design” says Jared Spool about Design Sprints. “When the executive shows up, the team can present the data along with the design that emerged from it. Demonstrating the data behind the design decisions, reduces the potential for negative influence the executive can assert, and smart executives will embrace the approach.” Collaboration, Not Consensus Prioritization can be polarizing because it’s often perceived as choosing one person’s ideas over another’s. When people have something personal invested in an idea or feature that’s on the chopping block, emotions can run high. The solution is collaborating at several levels. It is the product leader’s job to connect with all the stakeholders and communicate to each of them why certain choices have to be made. It starts with developing a shared vision and purpose for the product. If the team doesn’t agree on the big picture, then they certainly won’t agree on a single feature. Getting buy-in to the company vision and the ‘why’ driving that vision are essential. Agreement and understanding of both the company and product vision give the team a North Star. What it doesn’t do is give them a method for prioritizing each task and feature. Stalemates can still occur even when the team is aligned on the vision. The key to breaking the potential stalemate is to not set consensus as the goal. Collaborating towards a solution doesn’t require consensus. This concept is not new to leaders but might be new to the realm of product leadership. Herminia Ibarra and Morten Hansen suggest in their article “Are You A Collaborative Leader?” (Harvard Business Review, July 2011) that collaborative leadership is the “capacity to engage people and groups outside one’s formal control and inspire them to work toward common goals — despite difference in convictions, cultural values and operating norms.” In collaborative teams, leaders still retain the authority to direct their teams if and when resolutions can’t be found. As necessary as it is to treat everyone in the team as equal human beings, there is a tendency to conflate this with equality in ability to understand the context. The UI designer on a team might have a strong understanding of their domain but will probably lack the industry experience and scope of knowledge that a seasoned product leader has. It’s easy for the members teams to get hyper-focused on their interests and domains. After all, we hire people for their specialities and focus. The job of the product leader is to help the team rise above thinking of only their individual contributions and consider higher goals. “As product managers it’s our job to make sure that the company is building the right product, but many (possibly a majority) of us don’t feel like we’re doing that,” says Christian Bonilla. How Not To Prioritize The Work Before we dive into the process for prioritization, let’s talk about how not to prioritize your strategic goals and activities. Specifically, we need to address the influencers, filters and lenses that are used to direct this kind of decision making. Knowing what filters not to use is as important as knowing what filters you should use.
Of course all of these are valid sources of information, just not in isolation and never at face-value. Knowing where the data or opinion comes from is as important as the information itself. Being conscientious about checking the origins and context of data helps make better use of that information. A Better Way To Prioritize The Work “Too often we think we have a good idea, but we’re starting on the supply side. We’re looking for excuses to build the thing that we want to build, and the real trick to going deeper with product is to learn to move backward and get into the demand side and ask: Why is this the right time? Why is this important? What matters right now?” says Ryan Singer, Product Manager at Basecamp. Singer reinforces that feelings and personal bias can often lead us astray. So if those sources of information should be either distrusted or double-checked, what sources should you trust? Prioritization is best done through the lens of the following objective criteria:
Feasibility is a technical consideration and will need the inputs of the technical team members. This would include back-end engineers, UI designers and front-end developers. It might also include technical partners that are providing services or support to the tech stack. Product leaders are not looking for personal opinions here, rather just what is technically possible versus impossible or highly improbable. Desirability is the customer-experience focused part of the analysis. This takes into consideration the needs of the end user, the interaction elements, affordances and how these are to be marketed or sold. This information can be gathered from the researchers, UX designers, marketing and strategists. In turn this information would have been derived from user tests, prototype validation and analytics. Finally, the viability of the work needs to be considered as a function of the overall business. This insight is provided by the product manager’s and relevant executives. Viability also includes factors related to the industry, regulatory environment, and financial oversight, or legal considerations. Outside research or data would be a relevant to any one of these three criteria, assuming it was validated and relevant. Constraints as Prioritization Filters Within each one of the three criteria above will be the consideration for constraints. For example, feasibility doesn’t just mean to answer the question “is it possible?”, it means to answer “how will this be made possible?”. Constraints like time, people, money and process serve as filters for prioritization too. Leaders and managers can filter their decisions through constraint-specific questions like, “will we have the time to do that?” or “do we have the skills right now to make this happen?” You can organize constraints into two large buckets; people and process. People is self explanatory. Process includes all the non-human things that contribute to the work being done. Let’s explore constraints further:
People: The first people question you need to ask is “do we have the right people for this work?”. If yes, then the next question is “which of our people would provide the best results?” This second question aims to align the best skills and personalities with the work to be done. Certain people work better under pressure and would be better suited for this time intensive work. They are not necessarily better strategists, designers, or developers than those people who work better when given more time. They simply operate better under pressure. The goal is to align their personalities and working styles with the outputs and outcomes being planned. If you answered “no” to the first question of whether you have the right team, then you’ll need to determine if hiring full-time people or using external people, like freelancers or outside firms, is the best option. This topic is covered in detail in another article I wrote on on hiring product people. Process (Time and Dependencies): There are lots of different processes for product teams to use. Some use a home-grown process, others use a standardized process, while most use a hybrid. For our purposes of product design projects we have a rigorous hybrid process forged from 12 years of experience. It’s hard to say if there’s a perfect process. I’ve certainly never seen one but I have noticed that the best processes are rigid enough to keep the team focused while flexible enough to deal with ambiguous reality. For a process to be effective, it needs to be deeply understood by the team. Apart from quality of the people, the process is the single biggest determinant of the success of a project. It’s less important what the specifics of the process are than the fact that the team has agreed to work in a way they generates successful outcomes. This agreement encourages the right kind of communication and speeds up decision-making. A key component of this process is the ability for the team to emphasize a part of the process over others. Every project is different and thus priorities are different. Using inputs from the initial problem-solving work the team can dynamically change the size of each part of the project, thereby showing relative weight and resource requirements of that part of the process. A project that requires more research (Explore) due to a lack of data or knowledge, and requires more prototyping (Solve) and iterative improvement (Refine), might look like this: Like an algorithm, a good process is made up of a series of steps that guides the team from a starting point to a predictable outcome. It’s important to know what steps make for the best outcomes. I’ve heard it said that any process is better than no process, but the truth is that bad processes can derail the best people’s intentions. Invest some time developing a good process that works for your team than battling through a bad process. Like an algorithm, a good process is made up of a series of steps that guides the team from a starting point to a predictable outcome. The two biggest components of any creative or technical process are time and dependencies. Time Constraints: The time constraint will be split into containers (sometimes called time-boxes) or cycles that make the most sense for what your team is trying to achieve. As a product design firm we prefer weekly or sprint style containers as it aligns nicely with our client’s product development processes. Your company’s cycles might be shorter or longer depending on the size of the team, delivery framework (e.g. Agile or Lean), or what budget you have available. The way in which you divide your time for delivery cycles is not arbitrary. For example, in startups, where the amount of funding often determines time available, a shorter delivery cycle is necessary. Selecting a faster cycle signals to the team that you’re going to need to ship features faster. This also means that there will be less time for research and testing, forcing the startup to adopt mechanisms for faster validation, i.e. the Design Sprint. Choose your time containers wisely. Dependencies: In the simplest terms dependencies are both the links between the steps and the relationships between the inputs and outputs. Managing the inputs through the process should produce the outputs you need. For example, if you determine you need 4-weeks to create and test a feature you’ll need time, money and people to do that work. Sounds like simple math doesn’t it? In the real world this is a little more complicated. Every time you add a feature you’re creating another object that is dependent on other things. As your product grows and adds more features, so to do the dependencies grow. In all complex systems, changing one thing leads to a domino effect on how other things work or behave. For example, if we spend money on one thing then there’s the opportunity cost of not spending it on another thing. We try hard to organize features into experiences and themes to understand their relationship to each other. What’s often missing in roadmaps and planning are the people dependencies. As you’ll see from the matrix examples in this product roadmapping article, it’s essential to acknowledge when people are going to be directly impacting the outputs. The designer that still needs to be hired, or the engineer that is on honeymoon for a few weeks, are going to impact your plans. Don’t ignore these people dependencies. Prioritize with the delays, flaws and inconsistencies in mind. Mapping Priorities Once the list of priorities has been developed create a visual artifact of those activities. We’re big fans of drawing and sketching the priorities into some kind of roadmap. Traditional roadmaps don’t work for us as they tend to be overly specific. We prefer themed visualizations that show immediate verses less urgent features and experiences. Some companies use a matrix to map out the priorities. By mapping criteria against the features in the prioritization list you can develop a matrix. Each feature or element is then scored in terms of its feasibility, desirability and viability. The final column, representing the total scores, represents the priority. Ultimately, the matrix aims to objectively focus on the most important theme and the order that they would be sequenced. If you’d like more details on how to do this check out this article on Building a Product Roadmap. Overlaying considerations for innovation can also be done with a this prioritization matrix. When there is a high value for each of the criteria there is high overlap and therefore a strong indication that this will also be a candidate for new innovation. Summary of Prioritization Considerations
Final Thoughts Prioritization can’t be done in isolation. It’s part of the strategic planning process of any product business. Furthermore, it’s essential that teams tie the resulting release schedules and roadmap back to value of the product. In the most customer-focused organizations, the team will collaborate with the executives to ensure the prioritization of work is mapped to the company vision and go-to-market plans. It follows that any prioritization work is dynamic. Prioritization doesn’t really end. As soon as you are done, you need to start collecting new data, analyze changes and review plans. Anything that has to do with humans is inherently temporary. Plan for a ongoing prioritization activity. Set this expectation for a rolling prioritization schedule with your team and you’ll find things run just a little smoother. Enjoy what you’ve read? Good, because there’s an entire book full of this stuff. I’ve been working with two masters of product Martin Eriksson and Nate Walkingshaw on writing a book that all product professionals can benefit from. Partly out of curiosity and on the back of our own experience, we’ve interviewed almost one hundred product leaders. Their insights and experiences will open up the conversation and take the lid off the mystery of great product leadership. |
My ThesisFeeling uncertain is the unspoken truth of working with others. As a veteran product leader, my work is about surfacing these truths by observing, prioritizing and executing on what makes people work well together in their context. ArchivesCategories |