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.
Some of the Research
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:
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.
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.
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.
Some Team Experiences
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.
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.
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 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 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.
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.
Key Factors to Success
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.
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.
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.
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.
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.
My 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.
My Leadership Principles
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:
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.
As I’ve had the chance to really think through my own philosophy and the underlying principles, it has helped me clarify my own leadership ideas as well as better understand how I expect my own leaders and managers to function. I expect that this will be subject to update as I continue to add experiences, but these underlying principles form a solid foundation from which to build, at least for me.
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.
So What is a Leadership Philosophy?
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.
Why Determine Your Leadership Philosophy?
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.
How to Determine a Leadership Philosophy?
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:
What is My Leadership Philosophy?
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:
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.
As you begin to reflect on your own leadership philosophy, you’ll begin to set the stage not only for how you lead others, but the kind of leaders you work with. I’m convinced that if more leaders and managers would reflect on their own philosophy as well, we’d begin to see significant changes across companies and teams. So let’s all begin to be that change by understanding our own philosophies and creating the kinds of teams and organizations that everyone will admire.
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.
At the end of every year I like to take a look back at some of the highlights. Things that happened personally & professionally, things I learned, books I read, products I loved, etc. So here is one of those posts.
My reading list from 2018 was fairly broad, as I love everything from science fiction to history to product management. And this year had some great reads from all of those categories. As 2018 draws to a close, I wanted to take a look back at some of my favorites and most influential reads from the past year.
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.
It was a great year of reading. I set a goal to read a book every 2 weeks, and I was able to do it! I’m planning on upping that goal for 2019, so hopefully I can keep up with an ambitious schedule and maybe even catch up with some of the current best-sellers (though that probably won’t happen).
Here is my full reading list as well (in order that I read them), including first time reads and re-reads:
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:
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.
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.
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):
One of the key features is the focus on themes. This has been critical in aligning the product team behind a common goal. It's also incredibly useful for discussion and alignment. When we introduce the themes, it opens the door for discussion around the possibilities. For example, if the goal is to launch to a new group of users, the themes may be focused around the key items needed for that group to successfully adopt. Knowing that this new group of users needs the ability to create portfolios then becomes a theme, with potential features or ideas that we can implement in order to make that happen.
The exciting thing about this structure is that it doesn't tie us down to any specific path initially. The goal is clear and the metrics are clear, but how we get there is open for discovery and experimentation. We aren't tied to a specific feature if that's not the best way to solve the problem. In the case of portfolios I mentioned above, the solutions may involve building that functionality, integrating with other applications, or finding some other way to fulfill that need for the user. A portfolio may not be the right answer at all, which is why we do discovery around the theme.
Of course, as we get further down the road, our level of specificity decreases. We simply can't know a year in advance what the solution to those problems will be. Or even what the most important opportunities will be at that time. We can certainly have some ideas and don't need to be afraid to share them, but we can't tie ourselves down to a particular course so far in advance.
A good roadmap helps paint the vision and strategy for the product. It outlines the key goals, often by quarter, and shows themes or opportunities that the team will be focused on.
If you're interested in diving deeper into roadmaps and alternatives to the way roadmaps have been done for a long time, I'd highly suggest Product Roadmaps Relaunched, which has a lot of great tips on better ways of doing roadmaps.
Ultimately a roadmap is about creating a shared understanding with our team, our users, and our stakeholders. It is not about creating a document in a specific format or with specific pieces. Part of that shared understanding needs to be that we will learn and iterate as we go. We're focused on solving problems, not releasing features. And while we may have talked earlier about a specific feature, if we can find better ways to solve problems and deliver value, many of the specifics may change as we go. Our roadmap is meant to help facilitate that understanding between groups and ensure alignment. It is about the vision and the value of what we're delivering. So hopefully more roadmaps can become helpers, rather than hindrances, in getting us to those end-goals. Roadmaps can be a critical tool for progress in product development. Even if we have a love/hate (& hate) relationship with them sometimes.
One of the biggest challenges a product manager will face (or an organization for that matter) is trying to elevate thinking and culture from a project level to a product level.
Project thinking is fairly pervasive. Many folks, especially in software development, have spent a lot of their careers focused on projects and project management. Large organizations often have PMO departments, focused exclusively on project management. It's not surprising, because project management has been around a very long time. And we as humans tend to think in terms of projects: things we need to get done.
So what is project thinking?
The focus of project thinking is delivery. This could be the delivery of specific features or software, or really the delivery of anything. From aircraft to houses. And because the focus is delivery, the primary measurement is on the timeline and schedule. Project management is specifically focused on the output, and is measured by how accurately we were able to estimate the timeline beforehand and then deliver the specified output on that schedule. Success is largely defined as taking the specs of something beforehand, setting up a schedule with milestones all along they way, and then hitting those dates.
Product thinking takes a fundamentally different approach. Rather than focusing on the output, product thinking is focused on the outcome.
This is a significant shift from the mindset of project thinking. Rather than focusing on timelines and dates, we focus on the goal we want to achieve or the job to be done. Because we're focused on the outcome rather than the output, it is much more difficult to put time constraints around the delivery, at least up front. Primarily because we don't necessarily know how we're going to accomplish the goal up front.
This kind of thinking can be quite the shift, especially for folks who have spent a lot of time focused on projects and project management. Many people are uncomfortable with the uncertainty of not having structured timelines and schedules that they can monitor on a regular basis.
So what are the benefits of letting go of project timelines in favor of focusing on outcomes?
First of all, it is ultimately the outcome that we are driving toward, regardless of how we try and get there. The main benefit of a product mindset is that we ensure that we get to the outcome more efficiently.
With a project mindset, we assume at the beginning that we already know how to achieve the desired outcome. Working from that assumption, we create a project plan and timeline full of the requirements and milestones, and then begin execution on that plan. If we're right, and what we assumed initially turns out to be the right solution, then we're in great shape. We just execute the plan and achieve the outcome.
But what if we were wrong initially? What if the solution we identified isn't going to achieve the outcome we had hoped?
That is where project thinking gets us into all sorts of trouble. Once we set a plan in motion, it can be very difficult, especially in larger organizations, to pivot and change. Once dates have been put in place and everyone has agreed on a plan, that is usually what sticks in everyone's minds, despite our best efforts to learn and adapt. And if we end up missing a date, it can cause incredible issues for teams and businesses.
But with a product mindset, we are able to learn and adapt as we go. We aren't set on dates and milestones, but rather are focused on learning and achieving the outcome. If something doesn't work out or customers don't respond well to one thing, we can take that into account, adapt, and still work toward the outcome we had intended without blowing up a beautiful plan that is everyone's focus.
Crucially, when problems arise (and don't kid yourself, they always will arise), product thinking allows us to learn and adapt, and stay focused on the outcome we're trying to achieve. In contrast, when problems arise and we're stuck in project thinking with its focus on the timeline, we will often get sucked into endless meetings trying to determine why our initial guesses were wrong and how do we get back on schedule. This ultimately leads to sacrifices in quality, work-life balance, and the outcome since we need to stay focused on delivering the output we initially agreed on (regardless if that is still the right thing to do).
A Project Example
We've been talking about a lot of concepts, so let's take a look at some examples to better illustrate these points.
A great example of a project is the construction of a house. My wife and I built our house last year. We went through the whole process of selecting the floor plan, choosing all the finishes and details in the house, and then paying large amounts of money to get it going.
When we started, our construction manager (who was absolutely excellent), gave us the estimated finish date. It was about 6 months in the future. Obviously there are many things that go into these estimates, and things often come up that throw the dates off, but since the construction of a house is a very repeatable process with defined inputs, a good construction manager can look at the plan week by week and determine when they expect to complete the work.
Our house was off by about a week, which feels like a bulls-eye in my opinion. One of the trades was delayed in getting their work done, so that set things back a few days, which had some ripple effects. But that is fine. It's expected.
When it comes to these types of construction projects, they are very much geared toward project management. Everyone knows what needs to be done and keeping people on schedule is a real key, especially since it wasn't just our house being worked on, but the whole development.
A Product Example
But does this kind of project management work everywhere?
No, it doesn't.
As much as we'd like to think of software development as construction, it isn't. The clearly defined plans and work don't translate to product development no matter how hard we try. While there is great comfort in well-defined timelines, that's not how we should do product development.
In a product I've been working on, there is a key problem I identified and knew we needed to solve in order to continue to broaden our audience and reach additional users. The traditional approach to this would be gather the requirements, scope out the work, and then build the features. But much to the consternation of many folks at my organization, I don't take that type of typical approach.
Once I understood the problem, I dove into researching solutions, from building the features to integrating third-party software. As I did this, it became apparent to me that the solution was, in fact, not to build anything. Rather than build new features or integrate someone else's software (in this case, it was a portfolio for students), the solution was to change what we were asking students to do. Rather than focus on the portfolio tool, we could simply ask them to create the portfolio pieces and then utilize whatever software solution they wanted to in order to showcase their work. The benefits to everyone would be significant. Students would be in control of their portfolio, and we wouldn't be tied to building software or using any specific vendor.
We would have never come to this solution with project thinking. This solution came about because I was focused on the problem and the outcome (getting additional users on our application) rather than building the next feature.
This type of result is typically the outcome of product thinking. And it can come at any point along the way. In my example above, we avoided doing any development work. But often it may take several design prototypes to figure out what will work. Or we may do small amounts of development work in learning what features will truly drive the outcome we want. No matter where in the process we learn, the key is that we are learning along the way rather than deciding on the course up-front and following a project plan.
The Right Way
So how do we do that? How do keep a product focus?
All products and product management involve some level of project management. We have to keep things moving along and it is (unfortunately) unrealistic to assume that we can work in environment where our stakeholders and partners won't expect some dates or commitments.
The key is to make commitments and project plans only at a point when we can do it with a high degree of confidence. So rather than committing to a specific path beforehand, we commit once we've validated what we're doing and have had a chance to really understand what it will take. Often that is a sprint or two into the work. That may feel really late in the process, but it is at the point when estimates and plans can actually mean something. Marty Cagan, in his book Inspired: How to Create Tech Products People Love, calls this type of commitment a "high-integrity commitment." We allow teams time to do proper discovery and research before asking for commitments.
And we also need to help others realize the benefit of product thinking. There is a reason many folks ask for dates and timelines. Part of it is because of old habits. But there are times when it is necessary for business and budgets. So we need to understand what the job of the timeline is in those cases. If it is to help sell the product, we should turn the focus from specific features to the higher level story. If it is to manage risk, maybe we need to help folks understand that the real risk isn't missing a date, it's missing the mark completely on what value we're trying to deliver.
At the end of the day, the whole purpose of product development is to deliver value to users and customers. Most of the time we don't know exactly what is going to deliver that value though. To think that we can come up with the right solutions up-front, sometimes a year in advance if you do annual planning and budgeting, is pretty unrealistic.
While project thinking focuses on coming up with solutions up-front and then delivering against a schedule, product thinking keeps the focus on the outcome. That involves some level of comfort with uncertainty and learning, which can be pretty hard. But if we want to get to the right outcome, and not just an on-time output, it is really the only way to work.
My personal musings on a variety of topics.