Sense & Respond

Hey folks -

After 40 years in the field, OKR's are finally having their day in the sun. Teams are using them to set goals that, in theory, help them become more customer focused and agile. In reality, these new goal setting attempts often end up with the 'same old' ways of approaching work and most teams barely notice a change outside of new syntax.

OKR's can be done well and can be powerful transformation agents if teams take the time to understand why they're different and how they help change what a team does and how it works.

To help with that I've created an online, self-paced video course (75 minutes) that teaches exactly how OKRs make all this happen in several short, concise, beautiful lessons.

Take a look here and let me know if you have any questions.

[Jeff]

Hey folks -

Recently I've been thinking about the future of project management in a software-driven, increasingly Agile and agile world. I wrote those thoughts down and shared them with Harvard Business Review last month. Take a read here: https://hbr.org/2021/05/how-project-managers-can-stay-relevant-in-agile-organizations

What's been your experience? If the world is iterating forward, what does that look like for project managers?

[Jeff]

For years I’ve worked with teams helping them increase the agility of their product development efforts, leadership and culture. The thinking went that with a culture based on evidence-based decision making, continuous learning and customer centricity the organization could overcome any obstacle thrown its way without a company-wide panic. Since we have a learning loop built into everything that we do and we respect the evidence and insight it generates we create the environment where course correction is not only welcomed, it’s celebrated.

One of the places where we haven’t focused this approach nearly as much is ourselves, and more specifically our careers. Most folks take a standard approach to their career path — the one we’ve all been taught. Go to university. Get a degree. Find an entry-level job. Work your way up to management. Get the corner office. Save for retirement. Incremental improvements based on the assumption that the next best job will always be there, as will those promotions and corner offices. The reality we’re facing today — even before the pandemic threw the business world into disarray — is that those assumptions are rarely true. The loyalty we show to our employers is rarely reflected back to us and that straightforward career path we were promised often ends up looking like a zigzag line, if it’s even continuous at all.

(My new book, Forever Employable: How to Stop Looking for Work and Let Your Next Job Find You, has more tactical exercises like this.)

Why then haven’t we taken a good look at applying the basic principles of organisational agility to our careers and professional growth? The amazing thing is that these principles can be grafted onto to your professional path very easily. Let’s take a look.

We start with a problem statement to solve:
I set out to become successful in software engineering and follow a traditional subject matter expertise career path. Given the increasing volatility in the tech space, lower barriers to entry and the commoditisation of software engineering, finding the next best engineering job has become increasingly difficult. This causes me stress and anxiety about how to provide for my family and ensure stability and financial security for the foreseeable future.

How might I improve my professional development activities so that I ensure I always have a broad spectrum of opportunities available to me as a next best step in my career? I’ll know I’ve achieved this when I see at least one inbound job opportunity that I believe is a good fit per month.

In this statement, we’ve identified the current condition, the challenge to that condition and what the target condition could look like in terms of outcomes — changes in the behaviour of my target audience (in this case, it’s employers).

We move on to declaring assumptions:
I assume that my target audience is made up of CTO’s at companies I want to work for (a specific industry or type of organization), and that that the benefit they would get from hiring me is a better software engineering team and culture plus less stress on their day to day workload.

I also assume that I can get their attention by posting short videos on YouTube that share some bit of my knowledge or expertise. My expectation is that this content will reach this audience and ultimately motivate them to contact me when they have vacancies.

We then write our hypotheses:
I believe that by providing short videos on YouTube showcasing my tech expertise to CTO’s at companies I want to work for, I will build a strong audience that will continue to grow and consider me for future employment.

I will know I am right when I have at least 1,000 subscribers by the end of the year and I receive at least one relevant inbound job lead per month.

Finally, we run experiments:
Before you set out to buy a $10k home video studio invest $10 in a steady tripod and position your iPhone on it. Record yourself in front of a whiteboard sharing a 5 minute video of something you feel would be valuable to the people you’re trying to influence. Post it to YouTube and tell everyone about it. See what kind of feedback you get, make another video and post it again.


This is one, very specific example of how to apply the same exact principles of agility and continuous learning we use in product development to your own career. The template is nearly identical. The variables will change based on how you’d like to proceed in your career and where you’d like to grow. Just like in product development, our ideas are not always going to be right about what’s good for our career or is a good next step. And just like in product development, our goal is to influence the behaviour of others in a way that benefits them and us. In this case, you’re not focusing on customers of products but consumers of your skills, expertise and experience.

Want to learn more about this? My new book Forever Employable has tons more information.

Product management has become one of the hottest job titles in most organizations. Is it really that different than project management? In short, it is. And the difference is fundamental because the nature of projects and products couldn’t be more different. The more an organization can embrace a product mindset, the more agility that organization exhibits, the better they can sense and respond. Let’s take a deeper look.
 

Project vs Product -- 3 ways to reframe your mindset

Projects end. Products are continuous. 

In traditional project management we usually work towards a fixed scope. There’s a clear deliverable at the end of the project and once it is handed over to the client or customer, the project is over. The team celebrates and moves on to the next initiative. Their responsibilities are effectively over for this project. The measure of success in this instance is the successful delivery of the project in a way that works as it was designed.
 

Is that the optimal solution? Does it provide real value to the users of that solution? Does it achieve the goals of the business that sponsored it? Generally speaking, this is not the responsibility of the team that built that project nor the project manager who drove it to its successful launch.
 

In contrast, products are continuous systems. Defined explicitly: products are the way an organization delivers and captures value. They don’t have an end. Products are never done. For example, when is Amazon done? When is a bank done? When is your hair stylist done delivering their service? When we view our work as a product we realize that delivering the components of that product are not the measures of its success. They are the continuous evolution (and hopefully improvement) of that product. Our goal when we approach our work with a product mindset is not to celebrate the incremental and iterative deliveries of features, functionalities and improvements but rather their outcomes -- the measurable changes in the behavior of the people who consume those products.
 

Delivering an output is designed to be an ongoing, uneventful part of building continuous products. Instead of celebrating each output, we focus on the outcomes we seek to generate to tell us whether this product is worth any more investment or effort.
 

Projects are linear. Products are circular. 

Because projects end, they have a linear planning process. We work from one phase to the next, handing off our work to the next discipline in the production chain. We ask each discipline to estimate their levels of effort and we put together a linear project plan or roadmap. Our goal is predictability and consistency. We often don’t account for variability or new discoveries because we want to provide a confident answer to the question, “When will it be done?”
 

Products continuously evolve and, as mentioned above, don’t have a specific “end” when they’re conceived. They’re designed to deliver value on an ongoing basis. As new feedback comes in from the use of the product, the team must respond to that feedback and adjust their plans based on this new information. The entire basis for Agile as the new way of working is based on this idea. As an organization learns new things (senses) about its product it adjusts how it responds to those things. The plan changes. The organization and therefore the product exhibit agility. This is critical to success in today’s rapid change environment. Product thinking ensures that our plans stay as agile as our products.
 

Projects are components. Products are systems. 

The continuous delivery of new ideas to market is where projects shine. But these deliveries are simply components of the overall system, the product. Each component may or may not deliver real value to the consumer and the business. Product teams optimize their ways of working to sense as quickly as possible whether this value is being delivered and realized and, if not, to adjust the planning and the system accordingly.
 

Why is this important? Because the consumers of our products are inevitably going to be other people. And these other people, we’re sorry to say, are almost always unpredictable. They don’t use the products as we imagined. They struggle to complete tasks we thought were simple. They abandon our products for seemingly more difficult or “older” tools because of familiarity. Our responsibility as product thinkers is to connect with our customers, understand these pain points and challenges and adjust our product planning to reflect the insights we gain from these conversations.
 

This insight is what allows us to plan the next set of components (mini projects) we want to introduce into the system (the product) remembering that our goal isn’t the deployment of these new components but rather the successful alleviation of the challenges the humans who use our products told us they were having with it.
 

Project managers looking to increase the agility of their teams and to build more of a product mindset in the way they work need to consider these 3 elements of product thinking. In addition, they need to carefully adjust the tools they’ve been using to match this new reality. The tools and methods we use for planning need to embrace agility and reflect that in the work project managers produce. Agile roadmaps provide guidance and direction but can’t commit to fixed time and scope, since it is unknown in a continuous system. The needs of the people we serve are continuously changing which requires today’s project managers to learn how to assess these evolving needs on a regular basis through regular customer interviews. Finally, the needs of the product teams will evolve as well. The tools, data, insight and feedback they require will morph as the product system evolves. As a project manager, it’s your responsibility to empathize with the evolving needs of your team so they can do their best work as well.
 

We have many more articles coming up on how to do these new activities and they are all part of the online course we’re building and launching soon right here with PMI. Learn more and sign up here.

At least once a week, we stand in front of a room of executives, leaders, managers and practitioners and ask the question, “How many of you work in an Agile way?” Without fail, 99% of the hands in the room go up. The other 1%, the honest ones, raise their hand halfway and wave it side to side indicating that they are “sort of” Agile. Why “sort of”? Because in most cases organizations are implementing Agile, the process. While these teams are going through the motions that Agile recipes dictate, they rarely see any increased value from this. Instead, we work with leaders and teams to help them increase their agility. Agility is an organization’s ability to react, in real-time, to new information, product insights, market changes and competitive threats. We believe the only way to do that is to build a Sense & Respond organization. 

We cover many dimensions of a Sense & Respond organization in our book with the same name. In this article we wanted to highlight the most important dimensions of this type of organization and call out how each of these dimensions increases the agility of our organizations.[We’ve highlighted a few important tools we teach people to use to achieve these goals. Stay tuned for news about trainings we’ll be offering to the PMI community on how to use these tools.]

Customer-Centricity

In a web-driven world where customers—both B2C and B2B—have overwhelming power, it continues to surprise us how many organizations still don’t put their customers first. Many companies never talk to their customers, instead making assumptions based on previous experience and hoping (yes, hoping) that everything will continue the way it always has. A Sense & Respond organization recognizes the customer as the ultimate authority on value. As our friend and consultant David Bland likes to say, “You can decide what a minimum product is but the customer decides if it’s viable.” In fact, the product has no value at all if customers don’t use it. We therefore teach the companies we work with to understand their customers deeply, to create empathy maps and proto-personas and to build a continuous cadence of conversation with them. These conversations allows your organization to “sense” how well you’re delivering value. And it’s this continuous customer-centric insight that allows your planning and decision-making to begin to be truly agile. 

Continuous Learning

I once had a ski instructor say to me, “If you’re not falling, you’re not learning.” Even if we work for large, established successful organizations, we cannot rest on our laurels. The pace of change today is too rapid. This means we must create an organization that values and rewards continuous learning. Organizations must sense through every channel available whether their products and services actually serve customers well. We work with our clients to build research plans, create interview guides and build bridges to frontline departments like sales, customer service (call centers) and retail employees. We balance this learning with quantitative data to ensure that we’ve got a 360 degree view of what our customers are doing and, just as important, why they’re doing it. 

Evidence-Based Decision Making
Sensing is worthless if we don’t respond. It’s our responses, their frequency and our ability to adapt them quickly that drives the agility of our organizations. Responses, while often guided by gut instinct and experience, should always be based in evidence. The insight you collect when sensing is that evidence. It provides the foundation for your teams to make the best possible decision they can at every moment and reduces the risk of those decisions failing to improve the situation. One technique we often teach is framing a decision as an experiment. Instead of making a big, potentially risky change to how a system, service or company works, we launch a small, low-risk version of it. And then we wait (not too long) to see how user behavior shifts due to this change. If the change we see meets our expectations and desired outcomes, we scale the change and optimize it. If not, we roll it back, begin the sensing process again to understand why it didn’t work, and try again. These short Sense & Respond loops are the muscle that organizations need to build if they want to increase their agility. 

Incentives
Organizational agility thrives when it’s rewarded. When teams we work with struggle to implement the Sense & Respond way of working we find there is often a conflict between what the team is being asked to do and what the team is being paid to do. The techniques that enable continuous learning and customer-centricity can be taught to product development and other types of teams with success (we do this on a weekly basis). But teams will not put these tools to use if that is not what the organizational culture values and rewards. In these situations we end up with the folks mentioned at the beginning of this article, the “sort of” folks. 

When we work with leadership teams, one of the things we stress is that while the processes, vocabulary, tools and techniques that support organizational agility are important to fund, train and promote, their full potential won’t be realized if we don’t change how we incentivize these cross-functional Sense & Respond teams. 

The Dimensions of Agility
These are just a few ways that we’ve seen organizations begin to increase their agility. Rather than simply implementing Agile recipes, they think more broadly about how to put their customers front and center and enable their teams to continuously learn from these customers. What have you seen work well to drive agility? What techniques do you use? Share them with us in the comments. 

Join us on Nov 8 for our first Sense & Respond webinar with PMI. Details and sign up options can be found here.