Do You Know Where You Are Headed?

This content is syndicated from LeadingAgile by Rick Austin. To view the original post in full, click here.

There is a saying that goes something like this: If you don’t know where you’re going, any road will get you there.

When we create new products or add new capabilities to an existing product, we typically do so in an effort to solve a problem. These product updates may often happen by delivery teams being told to go build these features without a clear understanding of the problem being solved. There is a lack of context. I expect this is why we see results noted in the Chaos Report where up to 64% of software features are rarely or never used. Here’s an example:



The context that is often missing is the problem; what we are trying to solve? This lack of context is likely a breakdown in communication between stakeholders and the delivery team. Why is it so important that the delivery teams have a clear understanding of the problem being solved? Delivery teams are made up of people that have years of experience building products and solving problems. We need to tap into this body of knowledge and experience to help us solve problems in better and more simple ways.

Bridging The Gap

What we need is a way to bridge the gap in understanding–some way of providing a clear context for the problem to be solved. There are many approaches we can use, but a couple that I have found to be effective include:

  • Product Visioning
  • Product Press Release

A product vision, in the way I define it, has two parts. The first is framing up a clear understanding of the problem to be solved. The second is the product position. (I’ll cover the Product Press Release in an upcoming post.)

Product Problem Statement

The format that I have used is adapted from Crossing the Chasm, by Geoffrey Moore:

  • The problem of (describe the problem)
  • Affects (who are affected by the problem)
  • The impact of which is (what is the impact of the problem)
  • A successful solution would (list some key benefits of a successful solution)

Very concise, right? That being said it is interesting to me at how long it takes to distill a problem statement into this simple format.

  • What is the problem? Is this a problem you are trying to solve for your customer? Is this a problem you are solving for your company through the creation of a product for a customer?
  • Who are affected by the problem? Is it a problem that impacts customers or potential customers? Is this a problem that affects the success of your company?
  • What is the impact? If a customer, are they spending too much time and effort to solve the problem? Are they unable to solve the problem at all? If the company, what are the drivers that cause us to want to solve this problem?
  • What does a successful solution look like? Is this solving a problem that has never been solved before? Are we solving a problem with better, existing solutions? What are the differentiators that would compel someone to use our solution to the problem?

Here is an example of a problem statement for making person to person electronic payments:


If you were on a team that is solving this problem, would this problem statement provide context?

Product Position

The product position is an optional element of the product vision but one that can be worthwhile to define. The format of the product position is:

  • For (target customer)
  • Who (statement of the need or opportunity)
  • The (product name) is a (product category)
  • That (key benefit, compelling reason to buy)
  • Unlike (primary competitive alternative)
  • Our product (statement of primary differentiation)

Again, a simple format but one that takes an interesting amount of time and focus to define.

  • One of the goals of the product position is to clearly define what differentiates our solution. Why does our solution solve the problem better than existing solutions? Why would our product be picked over some competitor’s product?
  • The target customer helps frame up whose problem we’re solving for–often in the form of a persona that describes the role and characteristics of the people for which we’re solving the problem.
  • The statement of need really helps tie our product to the problem to being solved.
  • The key benefits will often drive a list of features that we intend to deliver in the product that will solve the problem.
  • The competitive alternative may be an existing solution in the market, or maybe that no solution exists at all.
  • The final item in the product position is stating what makes our product the one to pick. Why is it better than the competition or the existing solutions?

Here is an example of a product position for the problem statement we saw earlier:



The product position may appear to be duplicative to the problem statement, but I believe there is value in creating both; especially to help frame up the scope of what we intend to solve. Those key benefits really help us focus on the minimally marketable features and eliminate unneeded capabilities.


I have found the product vision to be very effective in setting a context for teams. Understanding the problem we are solving for is super important and helps to create alignment. Not having this clarity creates risk in that teams may not align, and they do not focus on delivering the simplest solution to the problem. In larger enterprises that have many delivery teams working in concert, this alignment becomes even more important.

Having a clear understanding of where we are headed makes it much easier for your teams to navigate to the final destination.

The post Do You Know Where You Are Headed? appeared first on LeadingAgile.

Leave a Reply

What is 6 + 7 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”