Project Management

Sense & Respond

by ,
Jeff Gothelf and Josh Seiden, leading tech experts and founders of the global Lean UX movement, share their insights into how organizations can grow and thrive based on their ability to sense and respond instantly to customer and employee behaviors.

About this Blog


View Posts By:

Jeff Gothelf
Joshua Seiden

Recent Posts

Your next agile project: your career

Good Agile Teams Are Diverse Teams: How Diverse Teams Allow You To Solve Problems Early and Often

Moving from Project to Product: What Does “Product Thinking” Actually Mean?

Is Your Organization "Sort of" Agile?

Three Obstacles That Leaders of Cross-Functional Teams Face, and What To Do About Them

Viewing Posts by Jeff Gothelf

Your next agile project: your career

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.

Posted by Jeff Gothelf on: July 13, 2020 06:34 AM | Permalink | Comments (5)

Moving from Project to Product: What Does “Product Thinking” Actually Mean?

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.

Posted by Jeff Gothelf on: October 18, 2019 12:20 PM | Permalink | Comments (21)

Three Obstacles That Leaders of Cross-Functional Teams Face, and What To Do About Them

I used to live in the suburbs next to a guy named Jim. Jim spent a LOT of time outside in his yard with loud, gasoline-powered equipment and tools. His favorite tool, and the loudest coincidentally, was his leaf-blower. And while he did have a stellar looking yard, the noise that emanated from said leaf-blower on a daily basis—multiple times a day—conflicted with my work-from-home conference call schedule. Often.

Any sane person would immediately assume that the level of attention Jim paid to his yard was excessive. And they’d be right. But I lived next to him for 10 years and over that time developed a different understanding of Jim’s perspective.

Jim had an angled driveway that connected directly to his garage and house. Rainwater and snow-melt would flow down the driveway towards the garage and into a grate. If that grate clogged with leaves, branches and twigs that fell from the big trees around our houses, Jim would get water in his basement. This was the main driver of his leaf-blower obsession.

Jim would regularly show me how much debris he’d cleared each day and note that once again his basement would stay dry. By experiencing this situation together with my neighbor I was able to learn, quickly, why he was behaving in this particular way. This experience formed the basis of our shared understanding. Because we had done something together, at the same time we had a clear understanding of what happened, who it happened to and what drove the action. The only thing we had left to decide was what to do about it. (Spoiler: better headphones for me did the trick.)

Shared Understanding And Cross-Functional Teams

To increase the agility of our organizations we also need to build a team structure that builds shared understanding. In the old linear world, waterfall processes worked well. One discipline did their work, handed it off to the next discipline in line and repeated the process. Efficiency was the goal and the time to production of the final product—well defined and well-understood—was the measure of success.

The model that replaces discipline-based silos in today’s uncertainty-filled contexts is the cross-functional team. These teams are made up of individuals with the skillsets necessary to deliver an entire product from beginning to end. They work together on the same project or initiative at the same time. They discuss their work together on a daily basis and adjust their approach based on input from everyone on the team.

Cross-functional teams reduce the cycle time of learning, so teams can better understand whether their product is truly delivering value. The faster a team learns, the more agility it exhibits. Working together in short cycles (called “sprints” in the Agile world) builds shared understanding. Shared understanding—like the kind Jim and I had because we were neighbors —is the currency of an agile team. When something happens,the team doesn’t have to waste time explaining to each other what happened. They were there. They experienced it first hand together. Instead, the team can move to a far more productive conversation: “What are we going to do about it?”

Leaders who can help teams build shared understanding save time, money and effort and lead to an improved quality of their product or service. But leading cross-functional teams to achieve as much shared understanding as possible has its own challenges. Here are three challenges to consider as you work towards managing and increasing the agility of your organization.

The team leader doesn’t have the same technical or domain expertise as the rest of the team

If you’re in charge of a cross-functional team odds are you rose to that role through a specific discipline. Maybe you were a software engineer or a business analyst. You were probably very good at that job but you’re certainly not an expert on how every other discipline should do their job. One of the things we teach in our courses is to set clear goals and guidelines for the team. Then get out of their way. Trust the team to do their best work. If you don’t understand how they do their work consider running a series of discovery interviews— something we also cover in our online and in-person courses. Ask them questions like, “How do you make decisions?”, “What constraints do you have on your work?” and let them explain their process and decisions.

Aligning the team to priorities and building consensus can prove difficult

If you were to ask a cross-functional team what the most important thing they needed to do next was, you would get as many answers as there were disciplines seated at the table. All of them are right but which one is the number one priority? In this frequent situation it’s your job as the team lead to determine which priorities are currently critical to the success of the initiative. You probably don’t know either. In high-uncertainty contexts, this is normal! So what should you do? We teach the teams we work with to frame their work as testable hypotheses. This allows the entire team to express which features they believe they should move forward and how they will know it was the right decision. Teams test their hypotheses to determine which thing, if we don’t do it right now, causes the biggest risk to the project. That’s the one the team should work on next.  It doesn’t mean the other ideas are wrong. It just means that you are going to defer work on those items until these higher risk issues are solved.

How do we keep everyone “busy” throughout the entire initiative?

Throughout a project’s lifecycle certain disciplines will be busier than others at various times. In the early stages design and product management do a lot of work while during the middle the engineers pick up the bulk of the work. What do the less-busy disciplines do during those times? Since we don’t want to break the team apart and move less busy people to other projects for fear of breaking the shared understanding the team has created we need to learn what other skills these folks bring to the table. Can they talk to customers? Can they do QA or UAT testing? Can they build a presentation to educate other departments about the upcoming changes the team is building? In addition, these same folks can likely continue doing their core work. Not everything fits into a sprint and so there is almost always something for designers, writers, business analysts and project managers to do. As Josh recently wrote on his blog, “Agile teams should be doing all of these things continuously, in every sprint. You want to be researching continuously. Designing continuously. Building continuously.”

Shared understanding is the key to agility

Agility is a goal all companies should strive to achieve. Your choice of how to staff and lead teams will impact this goal significantly. The more cross-functional your teams can be, the more shared understanding they will gain, the more agility the teams will exhibit. Nevertheless, this staffing model isn’t free. It has its own challenges that, as a strong team leader, you can overcome with some training, some improvisation, some humility, and some creativity.

We’re working closely with PMI to build offerings that teach shared understanding, collaboration and agility and we’d love to hear from you. What have you seen work well on cross-functional teams? What has been challenging in making them work? Who have you seen do this well? Reply in the comments and let’s build a list of best practices.


We're collaborating with PMI to create new online resources, webinars and in-person events to help you build, maintain and scale your Sense & Respond organization. To keep track of what we’re building together sign up here

Posted by Jeff Gothelf on: August 21, 2019 06:57 AM | Permalink | Comments (13)

Sense & Respond: Managing projects in a world of continuous change


(Hello world! Welcome to the Sense & Respond corner of This is the first of what we intend to be a series of articles focused on the rapidly changing world of product development and management. We hope to provide you with practical, tactical tools and tips you can use to make your teams and organizations even more successful. Like something we said? Disagreed? Want us to cover something specific? Let us know in the comments. Josh Seiden & Jeff Gothelf, authors Sense & Respond)


For years now, we’ve heard that software changes everything. But what does this mean? Is it just hype, or is there something behind that?


It’s not hype. Software is changing everything for two big reasons. First, it is a new material, and making things with software is unlike making the things we used to make. Software is not steel, rubber, bricks or paper. The process of making software is radically different from the process of making anything else, and we—especially those of us who work in project management—need to pay attention and adapt. 


But the claim isn’t just that software is a different material. It’s that this material changes everything. But does it really?


Turns out, yes. Since Marc Andreessen made his famous claim that “Software Is Eating The World” in 2011, software has in fact gone on to eat the world. It has become the beating heart of every large company. Every industry and every service—from financial services to entertainment, from food production and distribution to utilities and transportation, from entertainment to law enforcement—just about every fundamental service that we consume is either managed, mediated, or delivered with software. Think about how this “digital transformation” has affected your work. You are not alone. The change has affected all of us, for better and for worse.


Sensing What The Future Will Bring


The biggest changes that software has brought is a result of the complexity of the software systems we build and the uncertainty that is complexity’s cousin. 


Think about your most recent software project. One of the fundamental questions we face in project management is, “when will it be done?” This is a surprisingly difficult question to answer well when we’re working in software. Why? Well the simple answer is that most software projects involve building new things for the first time. We reveal new dimensions of the problem as we’re working on solving it. This makes software notoriously difficult to predict, because this complexity tends to shred even our best estimates.


A more frustrating answer is that software systems tend to be complex, and unlock new patterns of human behavior. Who would have predicted in 2010 when Instagram launched that it would lead to this:


Yes, poachers in Africa are using innocently-posted Instagram and Facebook pictures from nature lovers to track and kill rare rhinos. These are the kinds of second-order effects that are difficult to predict, but illustrate the real consequences we face when we work with software at scale. Stuff that we only dreamed of in sci-fi novels is here now.


Responding to Uncertainty & Complexity

What if we told you that predicting the future was easy? Hopefully, you’d laugh at how absurd a claim we were making. Except that to some degree, we’re being asked to predict the future every time we come in to work.


You may not face the same high-stakes challenges from poachers that the folks at Instagram do, but your stakeholders ask you to plan and deliver work to create value, or to make some change in the world. That means that they’re asking you and your colleagues to figure out what will work and then deliver it.


How do you do that? How do you predict the future? What process should you use? What does governance look like? (And of course: When will you be done? :-)


You start by recognizing that many of the tools we used to manage work in the past work less well in today’s context. Detailed work plans, careful specifications, exhaustive requirement lists—these tools have their place, but that place is rarely on a software team. More often, software teams are using methods that let them explore uncertainty, test assumptions, and move forward based on the information they gather. 


Sense & Respond

Over the last few years, we’ve been speaking with PMI and the project management community about the changes in the world, and the new methods we’ve seen rise up in response. We’ve seen the rise of Agile, and the increasing importance it plays not only in software development, but in every part of management. 


We’re excited to announce our partnership with PMI. In the next few months, you can look for articles, webinars, and starting in the fall, professional training opportunities that we’re developing for the PMI community. We’ll help you understand how Sense & Respond methods apply to your work—not just software development work, but every type of project and initiative you take on—and we’ll help you add these tools to your arsenal. 

What does it mean to Sense & Respond? How can you manage a team or project using this approach? How can you be more customer-centered? More user-centered? Collaborative? Cross-function? And most importantly, how can you deliver value faster, more consistently, and more predictably in the face of complexity and uncertainty.

Posted by Jeff Gothelf on: July 15, 2019 03:50 PM | Permalink | Comments (20)

"If only God would give me some clear sign! Like making a large deposit in my name at a Swiss bank."

- Woody Allen