As Teem was acquired first by iOffice and then by SIQ, it was critical we establish a cohesive product vision and strategy to define Teem's positioning amid the market, competitors, and the portfolio of companies within our organization. So I created an analysis of user and market needs, Teem's positioning, and a vision and strategy for our product going forward. 

I worked closely with other members of our product, design, marketing, and engineering teams, and then presented and socialized this information more broadly to continue to gain support and help others both add to it and understand the direction we were looking to take Teem and the product. 

First, it was important for us to understand the market and the context for our company and our product, especially as we were coming out of the pandemic and more companies and employees were returning to the office in some way. 

Next, I focused on our users, their key needs in the immediate-term as well as the longer-term. It was important for us to consider the current situation, which was Covid-19 and a gradual return to offices, but also the longer-term situation which would likely see a complete mix of remote, hybrid, and in-office depending on the needs of the company and the employees. 

I also looked at the history of Teem, its place in the market, and its competition both directly as well as from other incoming solutions. 

Teem was built from employee experience first and then moved toward administrative tools. Unlike other competitors expanding in desk and room booking, Teem was built for the user in mind and was easier and more intuitive to use than other offerings on the market. ​

This was an important consideration because Teem was moving more into administrative tools while companies that started out more focused on admins were moving more into the employee experience. 

Finally, I reviewed the challenges that Teem was facing from a company standpoint, a product standpoint, and a market standpoint. 

Once we had thoroughly reviewed the the market, our users, our competitors, and our company, I crafted a product vision that could address the key needs of users, utilize our strengths as a company and positioning in the market, and focus our efforts on creating the most important products, features, and experiences for the new work environment.

In addition to the product vision, I also helped craft our product positioning. This was an important aspect given that we were part of a larger group of companies within a private equity portfolio and wanted to focus on the correct positioning within that group of companies and within the broader market. 

Finally, in order to achieve the vision, I crafted a product and company strategy that could begin to guide us in our prioritization of existing and new product development. We needed to focus our efforts on the right things in the right way, and this was the strategy for that.

With a vision and strategy in place, as well as an understanding of our positioning, we were able to really focus our development efforts and prioritize new features and products correctly. This was the beginning of a much firmer and better direction for Teem. 

Our son (coming up on age 6) has always seemed to speak our daughter's language (she recently turned 4). It has been an adorable thing to watch as a father as they've grown up together.

Even when it has been pretty incoherent babble to our adult ears, our son has seemed to understand fairly well what his little sister was saying. Often my wife and I would struggle to interpret some of the
requests of our daughter as she learned to speak. As we'd focus really hard on what she was saying, we'd try and repeat back what we heard only to completely miss the mark. Nonsense things like "you want bow tie gains?" Only to have our son sigh at us exasperatedly and say, "No, she wants a bowl of Teddy Grahams." Of course, Teddy Grahams.

Recently, I got to watch as our son took this concept to the next level.

Both of our kids love to create artwork of every kind. No piece of paper or Amazon box is safe in our house as everything gets quickly claimed for either an invention or artwork.

In this case, our daughter clearly had a vision for something she wanted to create but was struggling with some of the pieces. She threw down the cardboard. “It won’t stick!” she screamed.

Our son asked her what she wanted. “I want it to stick!” she replied.

A common response in our house to this might be to use more tape, or to ask to borrow the “sticky tape”, which is the packaging tape my wife and I use for our Etsy shop packages. But in this case, he kept digging in a bit more because it wasn’t clear at that point what our daughter wanted to do. Some of her artwork is, after all, quite modern in its aesthetic and often turns out to be a giant ball of paper and tape and cardboard.

So our son asked our daughter to show him what she had in mind. “I want it to look like this,” she said as she held up one of the pieces of cardboard. “Oh,” our son replied, “kind of like a wing?”

“Yes!” was her reply. “I want it to be an airplane. And I want it to stick here and here. And I want to some more cardboard here.”

Our son was able to get to the heart of what our daughter was trying to do. It wasn’t just about taping pieces of cardboard together like what it seemed initially. Or even taping cardboard to a box. It was really about creating an airplane that they could take turns “flying” in around the kitchen.

​
It’s easy, especially as product teams (whether product managers or designers or developers) to jump into problems and try and solve them. Sometimes it may seem like all we may need is some stronger tape to hold the cardboard together. Or more tape in certain spots.

Those tend to be the easier or clearer solutions. Users are having problems, and we can solve them through certain new features. But if we don’t take the time to really dig into the problem, we’ll likely miss the real issue.

In one of the products I worked on in the past, there was a tendency to add lots of “tape to the cardboard”. If you are familiar with Salesforce, you may be familiar with this scenario. If you are not familiar, Salesforce is a pretty powerful client relationship management tool. We were using it to manage clients, including interactions both inbound and outbound. That included calls, emails, chats, etc. If a user called in, for example, the reason for that call was selected from a list of possible options and then these reasons could be narrowed more specifically as needed by the customer service agent on the call.

The data from Salesforce was utilized to understand problem areas within our products as well within our customer service, so it was constantly being monitored by a lot of people. And a lot of eyes on it meant a lot of people wanting to make changes. Managers would request features such as additional fields or dropdowns within their forms in order to better classify data. This may have seemed like the right option initially, but it was often missing the bigger picture. When too many changes were made, the quality of the previous data became useless. And at an even higher level, the overall hierarchy of the data wasn’t good, so continually adding more options wasn’t going to help. In fact, it was only going to exacerbate the problem and cause future problems down the road.

Fortunately, we spoke the language of our customer service team. Whenever we heard that we needed additional fields or there was a request for a “small tweak”, we knew it was time to dig into something. We needed to really get to the heart of the issue — understanding the need to appropriately group and classify data — in order to get to the right solution. This was definitely not the easy solution. It wasn’t simply adding more tape to make things stick better. Ultimately it led to reworking the architecture of Salesforce and reimplementing different parts. It took a lot more time and effort than simply adding fields. But it was the right solution and the right thing to do.

The best way to do this is to learn, over time, to speak our user’s language. For my son, this has come from a lifetime of understanding my daughter. For the rest of us, we have to really take the time to develop an understanding of our users. So that when they say “this won’t stick” we can have the ability to not only to understand the meaning behind the frustration, but to also dig into the problem in the right way in order to get to the right solution.

In February 2013, Marissa Mayer, the new CEO of Yahoo, decided to put an end to remote work at the company. In the memo, the company stated “to become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices.” All Yahoo employees were expected to give up any remote working arrangements and get back into the office.

I had a similar experience several years ago at a company I worked for when a new executive came on board. After a short period of time, he introduced a similar policy to the one above. We were much smaller than Yahoo at the time, but had been an extremely remote friendly organization up to that point. He described his motives as much the same (though he did let slip a few times that what he wanted was to look out of his office window and be able to see everybody in his department, for whatever that is worth).

So is it true? Do co-located teams truly perform better? Are communication and collaboration truly better when physically close?
​
The conventional wisdom today seems to believe that co-located is significantly better. I’ve been personally told that all the research points to that. But having experienced both poorly performing, co-located teams as well as high performing distributed teams, I wanted to take a closer look at some of the research as well as experiences of others.

There have been a number of studies that have taken a look at co-located and remote teams. While there could still be significant research done in this area (and I look forward to more of it), there has been quite a bit written and there are some key points we can glean from these studies.

How organizations support distributed project teams: Key dimensions and their impact on decision making and teamwork effectiveness
In this study, the researchers looked at how organizational support impacts project teams both in the decision-making process and the overall effectiveness. Ultimately, it found three key contributors to success:

1. Strategic staffing is significantly associated with team effectiveness. The team members are a critical part of the overall success of distributed teams.
2. Training and tools provided by the organization are critical in high-performing remote teams.
3. Team autonomy is incredibly important for quality decision making, especially in remote teams.
   ​

Exploring Agility in Distributed Information Systems Development Teams: An Interpretive Study in an Offshoring Context.
While the primary focus of this study is on the agility of distributed teams, and the difficulties presented by remote work, it also has some key takeaways for the success of distributed teams that I found helpful.

1. Agility is multi-faceted. It has to do with the team members, the team culture, the technology, and the processes employed by the group.
2. Understanding and collaboration are key to success and effectiveness.
   
   

Leadership Dynamics in Partially Distributed Teams: An Exploratory Study of the Effects of Configuration and Distance
This study took a look at leadership in partially distributed teams, analyzing the different dimensions of distance such as geographic, cultural, and temporal.
The key conclusion was that leaders must assist the team in bridging the distances. It took a different kind of leadership to make this happen on the teams, and ultimately took effort from leaders and team members to be effective.

Supporting the development of shared understanding in distributed design teams
Shared understanding is a key measure of communication effectiveness, especially on distributed teams. Reaching and maintaining shared understanding is critical, both perceived shared understanding as well as actual shared understanding.

For teams to reach this level of communication and effectiveness, they need appropriate training and support. The tools that teams have access to are also very important in their ability to communicate, work on tasks, and reach a shared understanding.

This study also highlights the difference between homogenous and heterogeneous teams, noting that more diverse teams (diverse in background, experience, location, culture, etc.) will require more support initially.

Project Risk Differences Between Virtual and Co-Located Teams
It shouldn’t be taken for granted that there are different risks in creating and managing virtual teams as opposed to co-located teams. This study looked at 55 project risk factors that other studies have identified as important to project success.

Of the 55, seven were identified as greater risks for virtual teams as opposed to co-located teams. These included insufficient knowledge transfer, lack of project team cohesion, cultural or language differences, inadequate technical resources, inexperience with the company and its processes, loss of key resources, and hidden agendas.

Effects of team member psychological proximity on teamwork performance
Some studies have claimed that as team-member physical proximity increases, the frequency and quality of communication increases, resulting in better team performance. More recent studies have found that there is no effect of team-member proximity on team performance. The missing factor may actually be the idea of psychological proximity, which takes into account all the aspects of proximity for a team.

This study analyzed the psychological proximity factors (spatial, temporal and social) and their impact on teamwork quality factors (communication, collaboration, coordination, and cohesion). Ultimately, reducing social distance helped overcome spatial and temporal distance, and was the most important factor in team quality. Social ties are incredibly important among team members. The spatial distance can be overcome with the right tools and coordination, especially when supported by the broader organization. And some sort of synchronous interaction is needed for overcoming both social and temporal distance.

Summary
Most studies I reviewed showed that there are hurdles to remote/distributed teams. But these challenges can be overcome with certain adjustments. We’ll take a closer look at some of those below in addition to a few examples from other teams.

I personally have had the opportunity to work on successful satellite teams as well as high-performing distributed teams. The success of these teams wasn’t by chance.

My Team
At one company, I worked for several years with a highly functional, and highly distributed, development team. Our lead developer was remote as well as our UX designer. Two other team members were primarily remote, and everyone else on the team was partially remote on any given day. As the product manager, I shifted my mindset from an “in-office” focus to a remote focus. Even being in the office, we utilized the tools for effective collaboration across the entire group. It gave everyone the chance to either be present physically or dial in, whether from their desk down the hall or from their office across the country.

This type of mindset was across the team. We often took time to call other team members regularly, even just to chat. This mirrored the kind of discussions that often happen sitting together. Our developers pair-programmed on the phone and shared screens regularly. Our UX designer and I regularly brainstormed and prototyped over video calls.

Our team was intentional in our effort. We had to be, given our distributed group and the fact that we were working on the single most important product for the company. We made it work and were incredibly successful in developing and launching a brand new product (more on that in another post). We hadn’t read any of the studies above, but seemed to understand intuitively or from previous experience that we needed to put in the effort to bridge the gaps and create a cohesive, effective team.

By the end of my time with that specific team, we had successfully launched our new application to over 100,000 students, saving the company millions of dollars and setting the stage for significant growth thereafter.

InVision
I’ve been interested in companies that either have remote teams, are fully remote from the start, or have transitioned to being remote. InVision is a prime example of a company that built remote work into their ethos from the beginning, and then transitioned to being fully distributed as they grew.
If you’re not familiar with InVision, it is a prototyping and design tool widely used across the technology industry. I’ve been using InVision personally for many years. Since it was founded in 2011, InVision has grown to over 1,000 employees and is used by over 5 million people at thousands of companies worldwide.

The benefits of being completely remote have been significant according to the founder, Clark Valberg, and CPO, Mark Frein. These benefits have included the ability to hire without geographical restrictions, saving millions by not having office space, and building a better product.

InVision has been incredibly successful, and has done it with a completely remote workforce.

Automattic
Automattic is the company behind Wordpress, a popular content management system and site builder that is behind many websites on the internet. And it is a fully remote organization. While it also didn’t start out that way, it moved to being fully remote when it realized that it could better empower its employees by allowing them to work when and where they wanted, and after deciding that too few employees were showing up to the office anyway. Automattic now has hundreds of employees across more than 60 countries.

As described in this HBR article, there are numerous lessons from Automattic, as well as some very compelling reasons why remote work has worked so well for them. One of the keys is creativity. Creativity thrives online, and allowing people to find the best way to work allows them to be far more creative than they might be otherwise. That means allowing employees to work when they are most productive, and from wherever they are most productive. Additionally, being distributed allows Automattic to hire the very best people regardless of location (a common theme among the companies I looked at who favor remote work).

Automattic has been very intentional in developing its culture, and it ensures there is ample communication on teams by hiring right, providing good onboarding and tools, and then bringing people together periodically. Those steps have allowed Automattic to thrive as a remote organization, as evidenced by its growth and continued popularity of its products.

Zapier
Zapier has been a remote company since its founding in 2011. It has literally written a book about the subject as well. For those unfamiliar with the company, it allows a user to easily connect apps together to automate processes or accomplish any number of tasks. It essentially allows non-developers to accomplish development tasks that wouldn’t have been achievable before.

Many of the lessons described so far are the ones that Zapier offers as well, as described in an interview with the CEO. The key benefits of remote work for the company have been in attracting and retaining talent, and in overall employee satisfaction.

Basecamp
No discussion of distributed organizations would be complete without discussing Basecamp. Its founders have long been proponents of remote work, and they have also literally written the book about working remotely.

Basecamp was founded in 1999, and has had a longstanding remote-friendly environment. Though the company has stayed intentionally small, it’s longevity and growth is a testament to its values.
The keys to success at Basecamp revolve around the idea of allowing employees to do deep work — limiting synchronous communication, interruptions, and meetings — and allowing employees to do their best work, however and wherever they do that.

Basecamp’s style is significantly different than many other companies. It may even seem radical. But the general principles are similar to other remote companies and they’ve clearly found success in what they’re doing.

So what can we take away from this? How can we make our teams successful and high-performing?
In order to be successful, forming and maintaining a remote or distributed team needs to be intentional, as some of the keys to success are different than co-located teams. While either structure (co-located or distributed) can be effective, both types of teams need to be designed and led with intention.
​

1. Team Members: As a company and team, you have to get the right people on board. One of the core principles for hiring at Automattic is the idea of no heroes. Everyone has to be a team player and getting hiring right is one of the most important steps. It doesn’t matter if an individual is the most skilled person at what they do, if they aren’t able to function within the team with good communication and minimal psychological distance, then there are likely going to be issues regardless of whether the team is distributed or co-located.
   
   
2. Shared Purpose and Understanding: A team has to have a shared purpose and it must achieve a shared understanding. This was a critical component in one of the studies cited above. Shared understanding is achieved with a common vision and actual communication. 
    
   Whether it is a remote team or a co-located team, achieving a shared understanding is critical. And it can’t be accomplished with documentation alone. It has to involve the right conversations. 
   
   In the case with product teams, I’ve seen the idea of “good documentation” take the place of conversations. But that simply won’t work. Good documentation is often the result of good conversations, but the documentation is often a lagging indicator (or a facilitator) in product development. It shouldn’t be seen as an end in itself. I’ve seen co-located teams struggle with this often. So achieving shared understanding must be intentional, regardless of whether the team is co-located or distributed.
   
   
3. Leadership: As the study referenced above indicates, leadership is also a key to success for teams, especially distributed team. This is a common theme throughout the company examples as well. Successful remote companies have to have solid leadership in order to make it effective. 
    
   This is true at the team level as well. It takes a different type of leader to manage a distributed team. So getting the right skill-set and the right mindset is crucial to success. This is where decisions have to be intentional. It may be possible to have weaker leadership when a team is co-located without impacting the team. But to have a successful distributed team, there is less room for weak leadership.
   
   
4. Technology and Tools: A theme throughout the research, as well as the company examples, is the need for the appropriate tools. This is far more important for distributed teams than co-located teams. Having worked on remote teams and satellite offices, I can attest to the importance of this. If the tools aren’t there to support the team (specifically the remote folks), then the team can’t be successful. Fortunately, there are tons of tools available today. I’ve utilized many common ones such as Zoom, Go-To-Meeting, Slack, Teams, Lucidchart, etc. But there are so many others that look great (that I need to experiment with). The key fact is that bridging the distance with tools is critical.
   
   
5. Organizational Support: The successful companies above were supportive of remote work. And that’s a huge key. They were able to build a culture of remote work. This is critical for companies moving to remote friendly work (which should be everyone in my opinion). The organization, particularly those in the headquarters or in the main office, needs to be cognizant of remote employees. More on that in another post, but thinking “remote first” will help get everyone adjusted to the idea of distributed teams.
   
   
6. Effort: As cited above, a critical component in team effectiveness is the social aspect of the team — the relationships among team members. While this may be easier with everyone in the office together, that doesn’t necessarily mean that relationships will develop between team members. In fact, other studies have found that even working in the same office won’t ensure that teams build the appropriate level of trust. This happens when the distance is perceived as far, even if folks are a few seats.
    
   There is a certain amount of effort that has to be put forward to build teams, whether they are sitting together or are distributed across the globe. Without that effort, the perceived distance between folks will be large, and thus the performance of the team will suffer.

When managed correctly, distributed teams perform just as well as their co-located counterparts. But therein lies the rub: you can’t simply put any team together and hope for success.

It would seem that co-located teams may generally perform better because they take the path of less-resistance. There is more room for mistakes when everyone is together in an office. You may not need as strong leadership or as many tools to make co-located teams effective. The effort to communicate can be smaller and the amount of time to bridge some of the distance can potentially be shortened. That’s perfectly fine. But let’s stop claiming that one outperforms the other.
​
With intentional leadership and design, we can create high performing distributed teams. As we’ve seen from the research and the examples above, the limiting factors to remote work are often in the effort put in rather than inherent in the nature of the team.

Like what you read? Feel free to follow me over on Twitter (@kylelarryevans) or sign up for my newsletter, where I post other interesting pieces and explore a range of topics.

References:

Cash, P., Dekoninck, E. & Ahmed-Kristensen, S. (2017). Supporting the development of shared understanding in distributed design teams. Journal of Engineering Design. 28(3), 147–170

Cha, M., Park, J., & Lee, J. (2014). Effects of team member psychological proximity on teamwork performance. Team Performance Management.20(1/2), 81–96

Drouin, N. (2013). How organizations support distributed project teams: Key dimensions and their impact on decision making and teamwork effectiveness. The Journal of Management Development. 32(8), 865–885

Ocker, R., Huang, H., Benbunan-Fich, R., Hiltz, S. (2009). Leadership Dynamics in Partially Distributed Teams: An Exploratory Study of the Effects of Configuration and Distance. Group Decision and Negotiation. 20(3), 273–292

Reed, A. & Knight, L. (2010). Project Risk Differences Between Virtual and Co-Located Teams. The Journal of Computer Information Systems. 51(1), 19–30
​
Sarker, S. & Sarker, S. (2009). Exploring Agility in Distributed Information Systems Development Teams: An Interpretive Study in an Offshoring Context. Information Systems Research. 20(3), 440–461

In my post about Product Thinking vs. Project Thinking, I highlight the differences between the two mindsets. Fundamentally, project thinking is about outputs and timelines while product thinking is focused on outcomes and solutions. And while there are instances where project management is critical, applying project thinking (or project management) to the entire lifecycle of product development is incredibly problematic.

And that is what I see with SAFe (Scaled Agile Framework if you’re unfamiliar with the term). While its intentions may be good — and there may even be companies or situations where it is helpful — as a whole, SAFe is the wrong answer. It may be a project management dream come true, but the issues with SAFe are numerous and significant.

Practical Problems
From a practical perspective, there are several issues.

Layers of Process. SAFe adds layers of process to product development that don’t need to be there. For example, Program Increment Planning (PI) is a formalized process by which all teams plan out and discuss their deliverables for the next quarter and align with all other groups. It is a formal meeting that takes place for several days. Now, this may sound good on its face because communication like this is a good thing, as is the planning and understanding that can result from it. But the process by which it is accomplished makes it overly burdensome in practice and takes away a team’s agility both by forcing the set meetings at the set time, and by locking in many of the commitments of those meetings with little wiggle room after the fact.

By putting so much focus on the structured meetings and process, it also takes away the emphasis on continual learning. Discovery shouldn’t be happening once a quarter, but continuously. Same with prioritization. Locking in these important aspects of product development to be done only at specified times does a real disservice to teams.

Generally speaking, if you look at the diagrams and processes outlined for SAFe, you can easily understand why the entire thing is overly burdensome and complex. Rather than simplifying or streamlining, it bogs down the entire development cycle with unnecessary processes.

Layers of Management. In addition to the heaviness of the process, SAFe also add (or keeps) layers of management throughout the development process. From the development teams to release train engineers to epic owners and beyond. The many layers of management reflect the many layers of process, complicating the overall workflow and adding a lot of cooks to the kitchen. While this may look incredibly appealing to managers, centralizing a lot of control at each level, the reality of having so many hands involved is often confusion and slow-downs as everyone steps on each other’s toes and each group may have different ways of doing things.

Additionally, it removes too many teams and people from the impact of their work. Instead of having a product owner or team responsible for features, and another layer responsible for business communication and yet another layer responsible for market needs, a development team should know and understand all of those facets. How can anyone be expected to truly deliver value to users beings so far removed?

Stagnation. In some regards, SAFe could be considered remedial agile. I never like to get into the debates about what is agile and what isn’t — they tend to be unproductive and pointless — but SAFe isn’t about scaling agile for large organizations in the sense that it takes agile principles and applies them to large groups. Rather, it is about beginning to apply some agile principles to large organizations that have no other agile experience. This could be great for a large company that is steeped in processes and waterfall methodology. But if SAFe is the end rather than a stepping stone in the process, it will ultimately result in stagnation of teams and products.

Philosophical Problems
From a more philosophical perspective, the issues are even greater.

Focus on Methodology. SAFe begs for the focus to be on the methodology itself. With the heavy processes and prescriptions, it’s almost necessary. This, of course, isn’t unique to SAFe. It is a fundamental issue with many methodologies: the process becomes an end unto itself. Scrum has the same problem, where the focus too often drifts from creating value for users to optimizing the development process, as measured by story points, velocity, etc. Optimizing may be important, but it is a means to an end, not an end itself.

Lack of Autonomy. Second, rather than giving autonomy to teams, SAFe removes autonomy from teams and ties them down often to lists of features. Part of PI often involves determining the features of the next 3 months. That isn’t necessarily a bad thing, but it becomes an issue by locking a team into features rather than outcomes. SAFe also ties all teams together into release trains and other processes. Rather than allowing a team to function independently — experimenting, releasing, and learning — teams are all formally tied together and dependent on each other. Decisions that may have otherwise been able to be made independently are now constrained by the process.

Lack of Agility. The purpose of agile is to allow teams to be, well, agile. That means allowing teams to design, build, test, learn, and iterate. The focus is on outcomes, which may or may not be achieved by certain features. Having agility means being able to shift priority or feature in order to better deliver the outcomes. It allows teams to learn from their experiments and then make adjustments as they go. This type of agility is the antithesis of the planning and processes imposed by SAFe and project thinking in general.

Hiding the Real Issues. Finally, rather than addressing the real underlying issues, many of which are described above, SAFe can cover them up with its processes and prescriptions. If an issue an organization faces is too many interdependencies among teams, SAFe’s prescription adds lots of planning and coordination between those team prior to having work begin. That is great if those dependencies can’t be decoupled. But what about organizations where they can and should be decoupled? Rather than tackle the hard work of reducing complexity, we paint over it with more meetings and processes.

That includes complexity from a product as well as from a people structure. If there is too much hierarchy within an organization, SAFe realigns it, but doesn’t fix it. The real issue is likely too much structure already, and the solution may be to flatten the organization so that people can actually have ownership of their work.

Finally, rather than fostering better communication up and down the chain, SAFe adds too many layers. If the real issue is executive communication and buy-in, SAFe may seem like a good answer with its processes and pyramid structure. But it doesn’t address the underlying issue, which may be a lack of understanding or a lack of real involvement from executive leaders.

Theoretically, SAFe is meant to solve some real problems for teams and organizations. Unfortunately, it fails in too many regards in practice. By overburdening teams with heavy processes and prescriptions, it ultimately takes away too much autonomy and agility. Rather than supporting product development teams, it asks that product teams support all the layers of management above. This isn’t unique to SAFe, and managers too often have their roles backward in thinking their teams are meant to support management rather than the other way around, but it is ingrained in the process.

SAFe is another embodiment of project thinking. While product thinking is the solution for product development, it is easy to slip back into a project mindset where the goal is to map out features and outputs and then simply focus on delivering them on a specific timeline. And that is what SAFe does: it puts the focus on outputs rather than outcomes. Success is measured on committing to features and then delivering them throughout the quarter. Of course, this is great if you’re right about all your guesses ahead of time, but that won’t generally be the case. And when processes take the place of outcomes, it’s not good for teams, organizations, or users.
​
Ultimately, the focus should be on the users of our products and services. We should eliminate as many processes and constraints as possible to better allow our product teams to deliver value. That means reducing complexity and organizational overhead, not adding to it. Get the right people and the right goals, then get things out of their way. Principles will scale to any size, so get those right and you’ll find the right scaled structure.

In some recent conversations I’ve had, the idea of leadership has come up numerous times. From my own leadership philosophy to the leadership (or lack thereof) of those in positions of influence, I’ve had the chance to analyze leadership from several angles. This has led me to reflect on my own views of leadership, and how I’ve implemented those principles.
I wrote about the importance of establishing a leadership philosophy in my article 6 Questions for Determining Your Leadership Philosophy. As part of that process, I spent some serious time determining my own leadership philosophy and its core underlying principles. I wanted to dive deeper into it here, as a way of articulating my ideas and hopefully as a useful reference for others as they establish their own leadership philosophy.

Get the right people working on the right thing in the right way — and get everything else out of their way.

​The above statement is what I distilled from the principles below. It summarizes what I consider to be my key beliefs and how I view leadership, incorporating my core principles.
Leadership for me really is about getting the right people, creating a vision for what we’re doing and helping establish the criteria and roadmap for success. And then getting things (and often yourself) out of the way.
​
I didn’t start out with this summary though. I actually went through the process I outlined in my other article and began establishing principles that I believed were core to leadership, and my views on leadership. After several iterations, I refined my thinking to the principles below.

Get the right people
When it comes to companies, teams, or even projects, having the right people is the first key. It’s even more important than having a vision, because without the right people, you aren’t going to reach your vision regardless of how compelling it is.

In the essential book, Good to Great, Jim Collins talks about how successful leaders (Level 5 leaders as they are referred to in the book) get the right people on the bus before doing anything else.

“The executives who ignited the transformations from good to great did not first figure out where to drive the bus and then get people to take it there. No, they first got the right people on the bus (and the wrong people off the bus) and then figured out where to drive it."

This isn’t just for executives of large companies. It is for every team and group. The right people will make or break a product. You could have the greatest idea for a world-changing product. But without the right group, you simply won’t get there. That’s why as a leader, I think it’s crucial to find and keep the best people. I added the idea of keeping them because the best people will have lots of opportunities elsewhere. So you have to actively work to keep them within your organization. Unsurprisingly, teams that stay together longer perform better.

So how do you get the right people? While this isn’t an exhaustive list, I’ve found at least a few key ideas to be critical:

1. Create the right environment. This includes the culture of the team or organization, but it obviously goes beyond snacks and ping-pong. It is an environment of continuity and psychological safety, where people can take risks without risking themselves.
2. Listen to and understand your people. They are the most important resource you have. So you need to get to know them. As a leader, you should really know and care about those in your group. It goes beyond regular “one-on-ones” or formal meetings. It needs to be at a more personal level.
3. Develop your people. You should help to develop those in your group or organization in such a way that they have the skills to leave for any job they could want. This not only enhances your current employees, but also creates a culture that other people want to be a part of.
4. Treat them right. Obviously, you don’t want to lose your best talent, so you need to treat people well enough that, even after you’ve helped them develop, they don’t want to leave because of the opportunities they have with you.

People truly are the key to success, so this principle really can’t be overemphasized.

Establish Principles & Live Them
“When values are clear, decisions are easy” — Walt Disney

As a leader, I believe it is critical to establish personal and leadership principles, and to live by them.

Leadership principles. Part of this is the exercise here — creating a leadership philosophy. Without the right principles, you won’t fully understand the actions your taking.

Team principles. As a leader, it is also important to establish the principles of the team or organization. This helps guide the overall culture mentioned above, and sets the tone for autonomy. If groups can understand the overall guiding principles, they can make decisions for themselves based on those principles.

Personal principles. Finally, a leader should have personal principles that they live by. This may seem like somewhat of a dated notion, but it’s something that teams, organizations, and the world need — leaders who have good fundamental principles, such as honesty and integrity, that they live by.

Set The Vision
“ If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”That above quote by Antoine de Saint Exupéry (though it has a variety of different translations) really captures the essence of setting a vision. A leader shouldn’t be set on divvying up work and creating silos where each group is “optimized” for their task. Rather, a leader should inspire everyone towards a common goal. The vision is the driver, the inspiration that everyone is working towards.

Jeff Bezos has put it well when he says that we should be stubborn on the vision, flexible on the details. All too often we see managers being stubborn on the details (from how we use story points to how teams run meetings) while disregarding the vision. That’s the opposite of what a leader needs to do.

Define The Framework
Of course, it’s not necessarily enough to paint an amazing picture of the future that we want to create. As leaders, we do need to help establish the framework for success. While a vision may be years away, we obviously need to do work now that will move us in that direction.

I’ve long been a fan of Objectives and Key Results (OKRs) for this exact purpose. If you’re looking for some good books on this subject, I’d highly suggest Measure What Matters and Radical Focus, which are great reads.

Creating OKRs allows you and your teams to establish what matters most (objectives) and how you're going to measure whether you’ve achieved your objectives (the key results). This allows flexibility in how the objectives are achieved, but ensures that the most important things are getting the right attention.

By defining the framework, you can unleash the creativity of your teams to find the best solutions. This helps guide work toward the vision, but allows groups to be much more autonomous in how they work.

Give Continuous Feedback & Recognition
It is critical to give ongoing feedback to teams and team members. There is simply no other way for people to improve than to understand real-time what is working and what isn’t, so they can adjust accordingly.

The idea of an annual or semi-annual performance review is probably one of the most antiquated notions at this point. And the sooner it dies, the better off we’ll all be.

It amazes me that over 10 years ago, as a manager at the computer labs at BYU, my fellow managers and I had implemented a feedback system that is far superior to what many companies still use today. We actually had a mechanism for all employees to give real-time feedback to each other. That feedback could then be conveyed via managers or supervisors on a weekly basis. We were also doing a more formal review quarterly. But little of that information was new since it was being delivered continuously. Improvement was an ongoing thing.

In Measure What Matters, this is the type of system advocated along with OKRs. It is called Continuous Performance Management.

“To power positive business results, implement ongoing CFRs (conversations, feedback, and recognition) in concert with structured goal setting. Transparent OKRs make coaching more concrete and useful. Continuous CFRs keep day-to-day work on point and genuinely collaborative.”It’s also critical to give recognition as well. Different people will appreciate this in different ways, so it’s important to understand individuals. But everyone needs recognition. And leaders need to find ways to give that recognition.

Get Everything Else Out Of The Way
Finally, the last key principle is to get everything else out of the way. That often includes managers and leaders. Once you’ve got the right people on the bus, have set the vision and framework, you really need to allow them to do their thing.

In Powerful, Patty McCord’s excellent book about Netflix culture (that I actually started and finished after writing most of my thoughts here), she describes one of the keys of their success as eliminating as much process and overhead as possible. Policies and structures can’t anticipate needs and opportunities.
​
That’s why I included the quote at the beginning from Steve Jobs. It’s critical to get obstacles out of the way of great employees. And often that includes getting leaders and managers out of the way. Fundamentally, each layer of management should be in place to support those folks on the ground doing the work — not the other way around. If we find ourselves adding work because someone needs an additional report (or something to that effect), we’re doing it wrong. Leadership needs to be in support of the vision and the work, not a barrier to it.

I’ve had multiple occasions recently to reflect on my own leadership philosophy. Not only have I been asked about it explicitly, but in several conversations with friends and others, the topic of leadership has come up with both positive and negative examples. This got me examining my leadership style and the principles that make up my overall philosophy.
​
Reflecting on your philosophy can be a surprisingly useful exercise, because we don’t often examine many of the underlying tenets that govern our actions. But as we do reflect on it, we can begin to uncover not only our own beliefs and principles, but also the principles we value in our own leaders and managers.

When I think of a philosophy in general, it is the set of principles and beliefs that govern our actions and direction. It is made up of many different pieces that are all intertwined, guiding us through various situations.
​
So a leadership philosophy is made up of the core principles that govern the actions of a leader. Not only what they do, but the vision that they set and the policies they put in place to guide others.
I often see “philosophy” confused for “style”. While style will be influenced by philosophy, they are not the same. Style may be the implementation of philosophy, but it is not equivalent. Additionally, style can be much more determined by situation while the underlying philosophy, though subject to reflection and revision, should not be changing situationally. It should be much more resilient and all-purpose.

Everyone has a philosophy, even if they don’t determine explicitly what it is. All of our thoughts and actions, especially when it comes to leadership, govern our direction. So even without determining or reflecting on a leadership philosophy, you have one. You just may not know exactly what it is or how it drives your decisions.

By taking time to reflect (and write out) your philosophy, you can begin to have a much better understanding of the forces driving your decisions and leadership.

Additionally, you can start to measure where your philosophy and implementation may not be aligned. Are there practices you currently have as a leader that don’t measure up to where you’d like to be? Determining your philosophy and reflecting on it gives you the perfect opportunity to ensure they are aligned. Or what you may need to do if they aren’t aligned.

But what if you aren’t currently in a leadership or management role? For product managers reading this, hopefully you already recognize that even without managerial authority, you are in a critical leadership role. For others, I’d likely argue that you too are in positions of leadership, even if it’s not readily apparent.
​
Regardless, most of us likely have managers and leaders in some capacity. By understanding our own leadership philosophy, we can better recognize the underlying principles guiding our managers. This is important for working with managers and fulfilling our responsibilities. But it is also critical in determining where we will work best. If your leaders and managers don’t have principles that align with your own, how can you expect to do your best work long-term? Ensuring that we determine our own philosophy and then find leaders who also align with our principles is crucial to our individual success and happiness.

As I was thinking about this topic and fleshing out my own philosophy, I asked myself a series of questions that helped me begin to articulate my own philosophy. Here are some of the topics I used to help me determine my philosophy:

1. How do I currently lead on my team and in my organization? It’s helpful to take stock of what you currently do in order to understand why you do it.
2. How would I like to be perceived as a leader? This helps uncover additional principles that you may find important to your philosophy.
3. What gaps are there between what I do and what I would like to do?Are there gaps? If so, why?
4. What leaders do I admire and why? Understanding the philosophy of others and why you admire it will help you uncover your own philosophy. This can be famous leaders, or leaders you know personally.
5. What leaders do I dislike and why? This can also be famous leaders or leaders within your organization. I often find that the best examples for me are the ones that help me understand what not to do.
6. What are my personal principles? Your personal principles should align with your leadership principles and philosophy. This is, of course, your philosophy, so it needs to align with your values.

As I’ve had the opportunity to reflect on the principles of leadership that I value, I’ve been able to articulate my overarching philosophy and the underlying principles. I go more in-depth on my own philosophy in my post My Leadership Philosophy & Principles, but I’ll summarize it here as well:

Get the right people working on the right thing in the right way — and get everything else out of their way.

The key underlying principles for my philosophy are:

1. Get the right people
2. Establish principles and live them
3. Set the vision
4. Define the framework
5. Give continuous feedback and recognition
6. Get everything else out of the way

​Not only is this the way I try and lead, but it is how I want to be led as well. Understanding that and articulating it are critical as I continue to lead various teams and take on more leadership roles, but also in understanding the kinds of leaders I want to work with.

Influence is probably one of the most valuable currencies as a product manager. Because you likely don’t have a lot of authority, you have to rely on your ability to understand others and help them understand your perspective and ideas. 

A key part to influence is having and inspiring confidence. You must first be confident in what you’re doing and what you’re proposing to do. You also have to gain the confidence of your product team, since they are relying heavily on you for the success of the overall product. You need the confidence of your stakeholders and users as well. 
​
So how do you gain confidence in yourself and inspire confidence in others?

Confidence in Yourself
No one will have a lot of confidence in you if you don’t have confidence in yourself. So be incredibly confident, but also incredibly self-aware. Because taken too far, you’ll lose a lot of credibility if you’re unjustly overconfident or arrogant. 

Gaining confidence starts with a big dose of humility. I talk a lot about this process in my post about credibility deposits. By definition, you aren’t an expert initially. But you can get there. And as a product manager, you are expected to get there. It starts with acknowledging that you have a lot to learn and then setting out to learn it.

I’ve personally come into almost every product and project as somewhat of a novice. Years ago when I was working with the Money Markets and Liquidity team at Goldman Sachs, I knew very little about the products and environment. But I became an expert in the products we were offering as well as each piece of regulation and how it would impact our products. When new rules were released by the SEC, I went through nearly 1,000 pages in the course of a few days in order to review and understand the implications.

The same can be said for current products I work on. But as I’ve first sought to understand everything from start to finish, I’ve been able to build up not only credibility, but confidence. As you really dive in and get out of your comfort zone, you’ll be incredibly uncomfortable for a while. But that’s what it takes.

Another real key in this process is taking ownership. While the CEO analogy for product managers isn’t perfect, it is an apt comparison in terms of the knowledge you should have and the care you should take with your team, product, users, and stakeholders.

Confidence from your Team
As a product manager, it is critical to gain the confidence of the entire product team. You will be working together day-in and day-out. The success of everyone in that group is tied together. You succeed or fail as a team. So how can you gain the confidence of the group? 

Understand. Take time to understand the team. Understand how they work and who they are. Every team is different, so don’t assume that you understand until you’ve taken the time.

Dive In. I’ve found that one of the best ways to gain confidence from the developers, designers, and fellow product managers you’re working with is to dive in. Head first. Get your hands dirty in any way you can. You’ll likely make some missteps, but that’s okay. That’s how you learn. 

One thing that I’ve found to be incredibly valuable is to really be in the trenches, even when it’s not necessarily where you add the most value. I’ve been on the late night pager duty, taking the 2am phone calls when something breaks. And even without being able to really fix anything, staying up all night until it’s resolved. Really being part of a team means being part of it all the way.

Develop Technical Expertise. There is certainly a lot of debate on how technical a product manager needs to be, and it depends on the role and company. But more technical skills are rarely bad. And being able to code and understand the nuances of development go a long way in helping you gain the confidence of the other technical folks around you. Just don’t forget who the experts are.

Confidence from Stakeholders
Depending on the size of your organization, you may have a few key stakeholders or you may have dozens. Certainly as the size of the group increases, so does the complexity. But the principles remain the same.

Again, you need to gain an in-depth understanding of each stakeholder. This time it goes beyond the understanding that you gained for your team though. Because each stakeholder will have different priorities, needs, and styles of working. You won’t necessarily be aligned completely like your development team is. As I’ve worked with a wide variety of stakeholders across different organizations, I’ve founds that I have to continually tailor my approach. Here are some key considerations:

Understand the Business. As a product manager you need a broad understanding of the organization. That includes not only how your product impacts different groups, but how those groups then impact other groups as well. Without understanding the business and how everything aligns, you won’t be able to gain the confidence you need from the stakeholders in those areas.

Understand the Priorities and Constraints. Each group, department, or stakeholder will have different priorities. Hopefully these all align broadly with the business, but the reality is that they may not. You need to understand this. Often there may be competing priorities in different groups that can impact your product or team. You have to also understand the constraints that your stakeholders are operating under. Often there will be budget implications, results they are responsible for, or other difficulties they have. How can you expect to sell the vision of your product or get a stakeholder on board if you don’t understand the constraints they are under.

On the flip side though, by showing that you understand stakeholders priorities and constraints, you can gain a tremendous amount of confidence. For example, in one product launch that I did, we had to coordinate closely with another team in order to be successful in our release. However, they were incredibly short-staffed at the time. So working closely with the key stakeholder in that group, we were able understand their constraints, find the right level of help, and coordinate the right timing. It was a tough process. And it set us back from our target. But it was the right decision and ultimately earned us a great deal of confidence not just from that group, but from many others across the organization.

Understand the Individuals. Understanding individuals means understanding who they are, how they prefer to communicate, and what level of involvement they have or need to have.

This could potentially be one of the most difficult areas to navigate. And I’ve found that no matter how careful you are, you’ll likely run into trouble here (so don’t beat yourself up). Because everyone is different. Some stakeholders are very hands-on while others are largely detached. Some prefer quick summaries of highlights, others want to know all the details. Very much like tailoring roadmaps, you have to tailor communication and involvement.

A word of caution as well. Don’t assume that little involvement or delegation means that the stakeholder doesn’t need to be involved. It may seem that way, but there are few things that grind a product to a halt as quickly as a stakeholder coming in from the wings because they haven’t been involved enough. Err on the side of too much communication and too much follow-up. 

Confidence from Users
Finally, and maybe most importantly, you need to gain the confidence of your users. This is such a broad reaching topic that it could likely be many posts all on its own, especially across a product’s life cycle. But we’ll hit a few key points here. 

Understand your Users. You need to understand your users. Empathize with them. Know what their problems are and what they need from your product. This will not only help you deliver a great product, but will help you gain confidence along the way.

Get them Involved. Do user testing early and often. Find your users or potential users and watch them use your product. Get their feedback. This is probably one of the best ways you can truly understand your users and deliver value to them. It goes beyond the metrics and gets to real understanding by watching real people really use your product.

Err on Their Side. If there is ever a choice between erring on the side of the business and erring on the side of the user, err on the side of the user. Every time. For one, you won’t have a business for long without users, but it will also show how serious you are about their experience. It will build their confidence in you and what you’re doing for them. Hopefully you won’t have to make this type of call often. But you definitely don’t want to be remembered for selling out your users for the sake of your business (*cough* Facebook). 
​
Deliver Value. Ultimately it comes down to delivering value to your users. Knowing what problems they’re solving and helping them solve those problems. Once you’ve done that, you’ll already have gained the confidence of some users. Build on that value and continue to deliver. 

Inspiring confidence as a product manager is critical. Without it, you won’t be able to accomplish much. But as you gain confidence in yourself and inspire the confidence of your team, your stakeholders, and your users, you’ll be able to work magic. And that’s what keeps most of us here, and what makes the role of product manager so exciting. 

1. Behave: The Biology of Humans at Our Best and Worst This was probably one of my favorites from 2018 as it was endlessly fascinating and actually led me to explore some other books around similar topics, such as The Willpower Instinct, You Are Not So Smart, and Mindset: The New Psychology of Success. The interaction between our genes, our environment, our ancestry and every other possible factor combines to make us who we are. It’s such a beautiful and profound complexity. 

2. Inspired: How to Create Products Customers Love
For anyone familiar with some of my other posts regarding product management, this book won’t come as a surprise. It is one of my top reads for product managers and has profoundly influenced the way I work. I’ve probably read it through a couple times this year as I’ve referred back to it in various scenarios. If you’re a product manager or involved in product development, this is one you’ll want. 

3. Foundation Series: Foundation, Foundation and Empire, Second Foundation
This series is incredible. I hadn’t read any of Isaac Asimov until this year, and I was blown away with how great this was. The original stories were published in 1942, which is crazy to think about. But it’s amazing how futuristic they still seem even today. If you enjoy science fiction, I’d highly recommend them. And I’ve already got more Asimov books in my backlog ready to go soon.

4. A Short History of Nearly Everything
I know I’m late in discovering this one (I’m always behind the times in my reading it seems), but what a gem. It’s a walk-through of, well, nearly everything in history. It is incredibly fun and kept me coming back for more with the clever writing and fascinating incites. It’s a great overview and refresher of everything you likely learned, and so many things you probably haven’t.
​
5. User Story Mapping
Going back to product management/product development, User Story Mapping is now one of my favorites. It is a great book on tools and techniques to use in building great products. I also had the opportunity to attend a session by Jeff Patton where he walked us through some of his key insights. If you ever get the chance to attend a workshop with him, don’t miss it. Worth every second. In the meantime though, you can definitely get a ton out of his book. 

When the only tool you have is a hammer, every problem tends to look like a nail. 

A persistent problem I keep seeing is that some long-standing practices tend to take the place of better ways of doing things. I wrote about the example of product thinking and project thinking here, which is one way this happens. But so many other areas of product development are prone to this same problem. Rather than understanding the underlying issues and determining the best way to address, we can often fall into old habits or familiar thinking. Many times it’s not even a bad way of doing things. But we (and our organizations) can do better.

So how can we get out of some of our bad habits? How can we take our thinking to the next level?

Elevating Our Product Thinking

Understanding Problems over Gathering Requirements

The term “requirement” makes me cringe a little bit, and I try to avoid using it whenever discussing problems to be solved. The connotation of it implies a rigidity that simply doesn’t work for modern product development. And the way it has been used for years leads too many people to think of it as an order that is taken by the product manager or product team and incorporated into the product. It’s a requirement after all.

Gathering requirements has been happening for a long time, which is why it is such an ingrained way of doing things. But I’d argue that if you’re only gathering requirements and then prioritizing them, you’re missing most of the opportunities to build a great product and experience. 

A requirement in this sense is really an initial idea or guess at a solution. And usually our initial guesses are wrong (sorry, but it’s true). That’s part of the reason I love the jobs-to-be-done framework (and one of my favorite books on the subject is Competing Against Luck). If you simply stop at gathering requirements, you haven’t gotten down to the actual job to be done — to understand the underlying need and if there is a better way of meeting that need.​ 

To get to this level of understanding, we have to go beyond “gathering requirements” to truly understand users. A great way of doing this involves journey mapping and story mapping. (More to come on story mapping later, but if you haven’t already read User Story Mapping, go get it now. Absolutely a game changer.) As an example, we were recently going through the experience for a subset of users of our product. One request they had was a button to export data to Excel. If we would have stopped at that level, we would have missed the real need. As we dove into that request (or “requirement”), we found that the export was an intermediary step. The ultimate goal was to get the data into Salesforce. So what they really needed was to get information into a different system, not an export to Excel. These are the kinds of things we find as we really understand our users rather than simply take requirements.

Outcomes over Output

It is very easy to get caught up in the output. Output is easier to commit to and easier to measure. Delivering a feature is easy to understand. We committed to a feature, we built it, and now it’s out there. Done.

But this kind of thinking the creates poor experiences or features that no one uses. Rather than simply building features, we need to focus on the goals we’re trying to achieve. Building a feature is only part of that. We have to ensure that the feature helps us reach the goal. If it is meant to get more users, did it achieve that? If not, what is our next step to achieve the goal?

This is a major focus of our roadmaps, and what we’re trying to achieve with a good strategic roadmap. I wrote about this at length here, so I won’t belabor the point. But the focus should be on outcomes rather than outputs.

Value over Estimates

Along the same lines as the above, it is easy to get into a vicious cycle of estimation, sizing, etc. This seems to be intended to give comfort to teams and managers that everything has been estimated and will only take X weeks to complete. But the cycle gets worse as initial estimates are missed, forcing everyone to participate in more meetings to determine why the guesses were wrong and how can we make better guesses in the future. This, of course, leads to missing more timelines, creating more meetings, and on and on and on. 

Do we really want our teams to be experts on guessing (if that’s even a thing)? Or do we want them to be experts on delivering value? Because we tend to put a lot of emphasis on one over the other. I’ve even heard it said that the mark of a good team is being able to give really accurate guesses. I’d argue the mark of a good team is being able to quickly and frequently deliver value to users. 

I’ve found that this type of focus on estimates and timelines can actually be a substitute for delivering actual value. In my experience, nothing has quieted the calls for estimates and projections like delivering actual results. It’s certainly no silver bullet, but can help us make significant progress. So if we could take back a little bit of the time we’re committing to estimating and projecting, and use that to start to deliver small increments of value to users and stakeholders, maybe we can get out of the vicious cycle and focus on what we’re all trying to ultimately achieve: delivering value.

Shared Understanding over Comprehensive Documentation

In his book User Story Mapping, Jeff Patton gives some incredibly useful advice when it comes to documentation, particularly around requirements and user stories. First off, “You and everyone else will learn that stories aren’t a way to write better requirements, but a way to organize and have better conversations.” The purpose of stories isn’t to have some sort of complete documentation of the requirements on what to build (see above), but they are the starting point for the conversation. 

The goal is to get to a shared understanding. Again from Jeff, “Stories get their name from how they should be used, not what should be written.” Most of us are probably familiar with the format of a story: As a [user] I want [a thing] so that I can [accomplish something great]. But it’s not about the format. It’s about the conversation.

It’s still far too common to think of handoffs between groups as the way of doing things. Siloing people into buckets/areas of responsibility that don’t cross over. The stakeholders give requirements. The product manager documents them. The team builds it. But that is how terrible software gets made. What we need is more collaboration between groups. The product manager should facilitate the understanding. The development team should be involved early on with stakeholders and users. The right solution is a joint effort, not a series of orders or handoffs down the line.

This goes not only for the stories, but also for acceptance criteria. Too often we look at acceptance criteria as the final word on what should be built. But the same theme applies. If acceptance criteria are created before a shared understanding, they’re likely to be wrong. What we need is team collaboration on what is being built. And that’s not to say that good acceptance criteria for features aren’t important — they are — but rather that they shouldn’t take the place of ongoing conversations and shared understanding.

Just-in-Time Refinement over a Comprehensive Backlog

Another concept I’d challenge is the idea that a team should have months of refined stories ready to pull into sprints, so that the next few months are planned and ready to go. Again, not that I’m opposed to the principle of planning and refining. I’m actually in favor of both of those things. But do we really know exactly what we should be working on in a few months? If we plan out all the details today, do we expect there will be no changes in 3 months? No learning that will take place between now and then?
​
A better way is to get continually more granular as we get closer. We can certainly have a plan for the next few months and next few releases. Even to the feature level. We should be looking ahead and understanding upcoming needs and priorities. But shifting focus from our current priority to the planned priority 3 months from now, and trying to get the same level of detail for both, is the wrong focus. We can’t, and shouldn’t, think that we can fully prepare stories and development work, then let it sit for a few months, and simply pick it up and begin coding when its turn comes. Rather, our energy is much better spent on the specific details of the very near-term, the broader details of the short-term, and the strategy of everything beyond that.

High-Integrity Commitments over Comprehensive Project Plans

All too often we fall back into the trap of putting dates on every possible feature and commitment from now to the end of the year (or other time period). The idea of a comprehensive project plan that will guide all our work and hold the team accountable is fraught with problems. 

​In one of my favorite product management books Inspired, Marty Cagan talks about high-integrity commitments. The idea being that we shouldn’t be putting dates on every single thing we do. Rather, we should only be making commitments to dates when it is necessary for a very good business reason. And when we commit to dates, it’s not a wild guess, but a well-researched and understood date that both sides can agree on. And we do this only when it is crucial. That way commitments to dates are meaningful. 

Again, we put the focus on the outcome we want to achieve, not the output. And we don’t drive our teams to exhaustion with endless dates. We make and keep meaningful commitments. And they are meaningful because they are not the norm.

Real-World Experience over Textbook Simplicity

Finally, every approach needs to be modified for the context it’s being used in. There is a ton of great advice out there, and many great examples of how to do things well. But almost everything will need to be modified and adjusted for the world you’re working in. It is one thing to understand the principles and methods. It is another thing to appropriately apply them to the user cases and business problems you’re solving.

That is part of what makes product development and product management such an exciting and difficult thing. It is as much art as it is science. There isn’t necessarily one “right” way of doing things, as much as we may want to think that.

It is a balancing act. On one side there may be folks who say things like “that will never work here.” On the other side, there are folks who say things like “all you need to do is XYZ. It’s easy, I’ve done it before.” Be wary of either mindset. While we want to continually push for best practices, some of them need to be modified to fit. But that certainly doesn’t mean it can’t work here.

At the end of the day, the goal is to improve the lives of the users of our products. But we often can get caught in mindsets that keep us from achieving that goal as effectively as we might otherwise be able to. Often we have to get out of our comfort zone, and help others get out of theirs as well, in order to do great things. ​

If I could pick one thing to kill because of the problems it causes, roadmaps might very well be at the top of the list. And it's not that I don't like roadmaps, or at least the principle of product roadmaps. It's the misunderstandings that they bring. Sometimes the misinterpretation of a roadmap actually causes far more problems than the roadmap sets out to solve. Why is that? And what can we do?

Purpose of a Roadmap

The first thing is to really understand the purpose (or purposes) of a product roadmap. Fundamentally, a roadmap is a strategic document used to create the overarching product vision, articulating the value you're delivering to users and the business in order to gain support and alignment. 

I break this down into a few key categories:

1. Inspiration and Vision: A roadmap is meant to help others see the vision of what we're doing. This is one of the most critical purposes of a roadmap because without a coherent vision, no product will be successful and no team will be functional. 
2. Communication: A roadmap is a communication device. It is meant not only to inspire, but also to allow users and business partners to know what is coming up and where the focus will be. It helps take the overarching vision and make it understandable and clear. Many groups simply need to know what's coming in order to prepare for it. And a roadmap is a great way to accomplish that.
3. Discussion: The roadmap is meant to help facilitate discussion about the direction and focus of what we're doing. Hopefully once we've created the vision and opened the channels of communication, we can have the right discussions about the problems we're solving and the outcomes we're focused on. This is critical because we also want to get feedback on our roadmap. It can be the first "test" of our strategy ensuring that we've prioritized correctly. That feedback can be invaluable in ensuring direction and buy-in.
4. Alignment: And of course, once we've had the critical discussions, the purpose is to get alignment around our product strategy and outcomes. A roadmap facilitates all of this communication and planning to ensure our product team is focused on achieving the right outcomes for our users and our business. It helps align our product teams and our stakeholders so we're working toward a common purpose and goal.

All of these pieces are crucial, because a roadmap is a living document. The purpose of a roadmap isn't to create an artifact that we can refer people to or post on a page somewhere. The items above are a continual loop as we learn iterate. By creating the vision, having the right conversations with users and stakeholders, and adding the learning that we get as we progress, we can continually refine our direction and plan for the future.

So Where Does This Go Wrong?

The purpose of the roadmap sounds great. Who doesn't want to inspire their users and stakeholders while ensuring everyone is strategically aligned? Why would anyone want to kill that? Where does this go wrong? 

A roadmap is not a project plan. Far too often a roadmap gets confused for a project plan. A roadmap isn't meant to be the detailed execution of specific projects. It's not meant to commit to dates for releases or timelines for features. There is certainly a place for that level of specificity, but it isn't the roadmap, especially as we look several quarters into the future.

A roadmap is not set in stone. This is probably one of the biggest problems that many of us have faced. Far too often a plan is put in place at the beginning of the year with themes or focuses for the entire year. And we get stakeholders or users who view the roadmap as a commitment to those specific items, even if we find we need to pivot along the way. This problem is exacerbated when the roadmap becomes a project plan with specific features called out far in advance and commitments to them made with dates. See this article for more about keeping a product mindset.

A roadmap is not a list of features or requirements. A roadmap should be strategic. It should be focused on the vision and direction of the product, and the problems we're solving. It is about the value we're delivering, not necessarily the features. While it certainly is okay to talk about features on the roadmap, especially the near-term features that we're confident in committing too, it's important to caveat specific features with the understanding that the features are meant to solve a problem or achieve an outcome. We aren't simply delivering a wish-list of features.

Key Principles

Now that we're clearer on what a roadmap is and isn't, what can be done? How can we craft roadmaps that fulfill the needs of users and stakeholders while still allowing us to learn and iterate along the way? 

No two roadmaps need to necessarily be the same. And I won't advocate for any specific template over another here. I've used variety of different types of roadmaps and they all have benefits and drawbacks. There are a few key principles that are true of most roadmaps. 

1. Focus on Outcomes: As mentioned above, the key purpose of a roadmap is to convey the benefits and outcomes of our product development. So any roadmap we create should focus on the value we're providing and how we can measure it.
2. Understand the Audience: You will likely have a variety of groups interested in your roadmap. Each audience may need different things. Executives may be more interested in financial implications of the product development while customer support needs to know what new things are coming so they can be prepared for questions. This may entail tailoring the details of the roadmap to the audience (though I'd avoid maintaining completely separate roadmaps and just focus on different things for different groups where possible).
3. Keep it Clean: Don't get too bogged down in details in the roadmap. As mentioned above, it's not the place for the project plan. It's not the place for extensive details. They will only confuse users and stakeholders and raise lots of questions. It's about the shared understanding. Stakeholders who are intent on getting into details can refer to the project plans or backlogs if necessary, as part of a separate conversation.
4. Convey the Vision: Ultimately the roadmap is about telling the story of your product and getting alignment on the direction. Make sure that it is a cohesive narrative. Often this can be done in a simple, visual format. But in other cases having a longer form narrative may be appropriate.
5. Keep it Updated: Since the roadmap is a living document, make sure that it stays updated. There is no quicker way to lose the value of the roadmap than to let it become stale. If it is going to be the vision and direction of the product, make sure that it stays that way and that everyone is continually bought into that direction, especially as changes happen. 

An Example

What I have done with my roadmaps, and what (fortunately) seems to be becoming more and more common, is something like below (this is very simplified, but has the key ingredients):