Support: the product manager’s secret weapon


Great thoughts here from a guest blogger. As someone who cares about thrilling our clients with products that more than meet their needs, I truly appreciate the reminder to talk with your support team. We get lots of our best ideas that way.

Originally posted on Under10 Consulting Steve Johnson:

Guest post by Susanna James

As a product manager, you want to build products that people want to buy and that customers love. But when was the last time you actually heard from your customers about what they like or dislike about your product? How often do you consider customer feedback when you’re planning product updates?

For many product managers, the main channel to customers is through the sales team. Sales teams know which features sales are won on and which they’re lost on. Sales knows what features prospects are asking for and can place a direct monetary value on implementing such a feature request. But sales people listen to sell; they don’t always listen to learn.

Basing your product roadmap on ad-hoc promises made to win a sale is a sure-fire way to lose sight of your vision for the product, and doesn’t actually address the needs of your end…

View original 937 more words

Let’s schedule a meeting for that

Today something happened that I have experienced multiple times in the past few years.  A question came up in our daily scrum meeting about the way two features need to interact in our product.    Both are new features (though they leverage some of our existing functionality) and the team has been making great progress on each of them.  When the question arose, those of us at scrum realized that we needed a particular subject matter expert with deeper knowledge of client expectations to provide clear direction.  So we decided to schedule a meeting to talk the issue through.

What if we didn’t need to do this?

One of the core practices of XP development is sitting together – having the entire team physically located in the same workspace so that communication is easier and faster and ‘meetings’ become less necessary.  James Shore and Shane Warden make the following observation in The Art of Agile Development: “My experience is that programmers on XP teams spend a far greater percentage of their time programming.  I attribute that to the increased communication effectiveness of sitting together.  Rather than sitting in hour-long meetings, conversations last only as long as needed and involve only the people necessary.”

In my experience developers are not excited to spend time in meetings, but they do want context – to understand why we are building the products and features on our roadmap – and they do have questions – sometimes simple questions that can be easily answered and sometimes deeper questions that require time to talk through.  If we don’t sit together, then the place to get that context and answer those questions is frequently a meeting.  But XP holds out the hope that it doesn’t have to be this way.  There are ways we could structure our space and our work so that necessary information can be shared without hunting for time available on multiple calendars and scheduling a meeting.

Sitting together doesn’t eliminate all meetings.  Regularly scheduled times for daily scrums, planning times, retrospectives, and feature demonstrations still need to happen.  But there are ways to dramatically reduce the need to schedule unplanned meetings when the team sits together and people can simply turn and talk with each other.  The useful regular meetings can generally be focused and time-boxed and if after the meeting when people ‘go back to their desks’ they are still sitting together then conversations can be continued by the couple of people most needed to make a decision and move forward.

As useful as sitting together can be, there are many real world complications to making it happen.  Our development team is scattered across multiple offices and time zones so we make extensive use of communication tools to capture as much of the ‘sitting together’ experience as we can.  There are over 20 people on our team (not including the consulting teams using our product internally and the sales and marketing folks who are working with our full suite of products and services).  We are probably too large a group to effectively sit together – even if we were all in the same office.  While on the one hand I spend a lot of time with the developers so that I can be as responsive as possible to their questions and as aware as possible of the struggles they are running into, on the other hand my desk is with the implementation, support, and sales teams so that I can have a clear picture of what our clients are encountering and how the market needs are being addressed.  My job would be tougher if I weren’t ‘sitting with’ both of these two groups during a typical day.  It would be great if there were a way for us all to sit together and therefore we could eliminate the need for separate meetings, but in truth it’s not that simple.

Ship complete or ship on schedule: pick one


Steve Johnson regularly has good thoughts to share about Agile product development; hope you enjoy his words here.

Originally posted on Under10 Consulting Steve Johnson:

Perhaps the main reason we were behind schedule and over budget was because budgets and schedules are based on previous experience with similar projects. We really didn’t know how much it would cost to build or how long it would take.—Tom Kelly, Grumman, on building the lunar module for the Apollo program


I read an article that claims Agile Development has now reached the “trough of disillusionment.” It seems that executives and product leaders have started to pine for the good old days of waterfall.

You remember waterfall. We had lots of big documents and checklists and wonderful GANTT charts and status boards. And we were always sure what features would be delivered on certain dates.

Wait. What?

Did we ever hit our dates? The big lie of waterfall was that you could anticipate all requirements in advance. And that requirements didn’t change. And you’d hit your dates. And you…

View original 698 more words

Tell me a (short) story

I’ve picked again recently on the theme of Agile planning in this blog and thought I would continue with a few brief thoughts about the context for planning.  I talked earlier in this series (way back in January of 2014) about portfolio planning and product roadmaps that set plans for individual sprints and releases into a larger context of the corporate vision for product development.  Here I want to talk about a different angle for examining the context of planning.

Over the past couple of months we have begun thinking about ‘jobs to be done’ (from Clayton Christensen – see more here) rather than user stories or epics as the way we conceptualize what to work on.  The key questions we ask in this approach are what are our customers trying to accomplish and how does this fuel the design and development of our product.  Why do prospects ask about a specific report, or why do clients want access to certain types of data?  What is the business problem they are seeking to solve and what can we do to make it easier for them to get the resolution they need?  The ‘job to be done’ concept in some ways parallels the ‘epic’ idea in that it often involves several components of a broader solution.

Discussing the job to be done with at least the lead developer and designer has a number of advantages.  First of all it gives them a wider context for understanding why we developing our product; the more deeply they can grasp the business needs of our end users the more they can utilize this insight in developing the architecture and features of our product.  Knowing the business goal also provides added motivation for the development team; when they know that they are building something that meets a real client need this can be more energizing than simply coding a new feature because the product manager said we want it.

While providing context and motivation for the team through discussing the job to be done is valuable, taking this approach has the added benefit of leaving the ‘how’ of product creation in the hands of the designer and developer.  Talking about the jobs our clients want to accomplish without specifying how to solve those problems allows the designer and developer the freedom to think about the technical approach that best accomplishes this job.

We are relatively new in seeking to utilize the jobs to be done framework to set the context for our product planning, but so far it has been helpful in providing a wider vision for the development team that sets our sprint plans in context.  We still need to break the solution into smaller pieces that can be worked on in individual sprints and even on specific days within the sprint.  The larger job to be done might break down into multiple user stories that each address one step in the problem solving process; then these user stories might be further articulated as specific tasks for the team to work on.

In our scrum team our typical tasks are estimated at between half a day and two days of effort.  I must admit that in thinking and writing about Kanban and XP lately I’ve been wondering if we should try for shorter ‘stories’ that can all be completed in less than one day.  This balance between wanting to give adequate context for the work we do (whether you call it a user epic or a job to be done) on the one hand and wanting clearly articulated tasks that can be estimated and committed to for a specific sprint on the other hand is something I continue wrestling with.  The ‘jobs to be done’ framework appeals to my big picture impulses but it doesn’t fully resolve this struggle because in truth it’s not that simple.

Never invite sales people to a meeting


Another piece well worth reading. Some key quotes:
– you want your customers to inspire the product, not define the product
– sales people are supposed to be selling

Originally posted on Under10 Consulting Steve Johnson:

clockIn a well-run organization, each role has a single orientation; they either support [individual] customers or they support the market.—Peter Drucker, American management consultant.

What do you think sales people should be doing?

(It’s not a trick question.)

The things you probably thought of were: building relationships with customers, helping them configure the right solution, negotiating, and closing deals. In short, selling what we have to people who want it.

In your list, did you also think sales people should be creating product presentations, developing ebooks, and determining the industry events to support?

Would you be surprised to learn roughly 50% of sales people’s time is spent working on things that do not generate revenue? In short, half the time, sales people aren’t working toward their objectives but are providing market expertise to the rest of the organization.

How often do you find yourself saying, “Let’s ask the sales people…

View original 457 more words

Personal planning: reflections on my own daily planning post

Writing my latest blog post on daily planning as part of the broader Agile product development plan got me reflecting on some of my own planning tools and techniques.  I wanted to share some of those thoughts here.

First of all I should acknowledge that I am a huge fan of planning.  I’ve found both personally and professionally that success and effectiveness are rarely stumbled upon; pursuing them takes conscious effort and part of that effort involves planning.  Yogi Berra once observed that, “If you don’t know where you’re going you might not get there.”  Planning entails deciding where you are heading and determining what steps are likely to get you there.

For me daily planning starts with a wider context of knowing my goals and having a sense of purpose.  Those of you who read this blog regularly know I am a huge fan of Stephen Covey’s 7 Habits of Highly Effective People (see my summary of these seven habits here).  From Covey’s book I take the notion that you have to ‘begin with the end in mind’ before you can ‘put first things first;’ it’s important to know what you are pursuing in every area of your life before you can effectively articulate strategies for achieving your goals.  These strategies then translate into plans with weekly and daily increments.  That might sound like a lot of preliminary work before getting down to practical daily planning, but for me at least having this broader context helps insure my daily plans are taking me in the right direction instead of simply helping me get to the wrong place more quickly.

I like to start my planning early.  Over the weekend I begin to plan the week ahead, and each night before bed I look at my calendar for the next day to make plans about when I will accomplish the key tasks in my day.  Even though much of my life as a parent and a professional is by nature reactive – responding to the demands that other people put on my time – I still try to schedule my priorities rather than simply prioritizing my schedule; I consciously block out times on my calendar to get done the most important things knowing that some of my time will be grabbed by other people or unforeseen circumstances.

In addition to starting with a broader context of life goals and reviewing my daily and weekly calendars in advance to make sure I block out time for key tasks, I have also found using a personal Kanban board very helpful.  I use KanbanFlow ( to create a board that tracks tasks that I am waiting to schedule, those on my plate for the week, those I am doing on a given day, and those I am actively working on to keep a readily available picture of my plans and progress.  The board is a great way for me to note things I know I have to get done at some point and to stay focused on moving forward with the most important tasks in my day.

The tools I use are often most valuable when I feel least like using them: when I am extremely busy and don’t have time to plan or when I have only longer term projects to chip away at and feel a correspondingly reduced pressure to plan well.  In the former case I am running reactively between multiple competing tasks and struggle to do much planning in the midst of this chaos; here the fact that I try to plan before even coming to work usually helps me keep my head above water but at times some important things slip as I scurry about fighting fires.  In the latter case, when I have no urgent matters clamoring for attention and only long-term projects to work on, it can be easy to get distracted by less important items; here it helps if I have taken some of the bigger projects on my personal Kanban board and broken them into smaller tasks so I can plan to work on steps toward these larger goals.

In spite of my best efforts and intentions for planning, life remains unpredictable.  Sometimes my well-planned days get completely derailed by unexpected events at work or at home or by unanticipated opportunities to pursue bigger goals that suddenly appear.  Planning my weeks and my days provides some basic scaffolding to support the shape I want my life to take, even when I have to adjust or abandon my daily plans in the face of life’s intrusions.  Drifting through life at the mercy of other people’s plans and priorities offers less satisfaction than struggling to pursue what matters to me, but I know that on many of my busiest days I have to admit that in truth it’s not that simple.

Daily planning

Many months ago I started writing a 10-part series on Agile planning (you can read the first post here if you want to catch up; then keep going forward from there to find the other pieces, most of which are tagged as “Planning”).  Since that ambitious beginning I got frequently sidetracked and so I never made it past the seventh section of this planned series.  Here I want to pick up where I left off and talk about part eight of that original plan.  I’ve already discussed the context for Agile product development planning, the importance of listening to the market to discern meaningful problems to solve, and the construction of roadmaps for both an individual product and the broader product portfolio.  I wrote about sprint planning (using the two-week iterations that we practice in my current firm as an example) and the need to incorporate new feedback both within and between sprints to ensure that the team is focused on building the most important thing.  With this post I want to talk about daily planning.

As a brief side note, I’ve been reading and learning a lot about different approaches to Agile this year.  I’ve been to several Scrum Alliance area meetings as well as their Certified Scrum Product Owner training (and I plan to attend their Scrum Master training in the fall with a colleague).  If you’ve been reading my blog lately you know I am reading a book about XP entitled The Art of Agile Development.  And for both my job and my personal life I have been exploring Kanban as a way to track the progress of items on my plate.  Elements from each of these approaches – along with other things I have read or learned about practicing Agile – have informed my own perspectives on this topic.

One key to daily planning is the daily stand-up meeting; Scrum, XP and Kanban all have a version of this as a core practice and it’s not hard to understand why.  Having the team meet daily to discuss progress from the day before, expectations for the current day, and impediments that block potential development facilitates the team’s focus on pursuing their sprint goals together.  This daily communication promotes collaborative problem solving, assures efficient knowledge transfer as new issues and opportunities arise, and keeps everyone aware of the team’s incremental progress toward the sprint goals and the broader product vision.  Brief daily stand-up meetings (even if folks are actually sitting down) serve a number of valuable purposes – including providing a forum to surface questions that can be addressed outside of the meeting itself – but they are crucial in my experience to allowing effective daily planning for the development team.

A second item that I have found very valuable in encouraging daily planning is some sort of visual representation of the team’s progress throughout the sprint.  This could be a Kanban board (learn more about these here if you aren’t already familiar with the idea), burndown chart (check out this link if you want more details on these) or some other way of representing what the team is working on and what progress is being made to get each task accomplished.  There are plenty of online tools that can provide this visual depiction, allowing even remote teams to have a consistent view of the most important tasks for the sprint and what stage of progress each item is in on any given day.  When larger tasks or stories can be broken into daily pieces (or smaller) it becomes even easier to plan for the day and for the team to track its daily progress.  Reviewing our Agile board at each morning’s scrum allows the teams I work with not only to decide clearly what will be worked on each day but also to know if we are on track to meet our sprint goals or if instead we need to adjust our plans.

Employing these elements of daily planning and cooperation leads to daily progress toward established goals even as it provides room to respond to changes.  With the frequent delivery of working software as a core principle behind Agile development, practices that promote and support daily delivery of incremental steps toward broader product goals play a key role in effective execution.  Balancing wider strategic goals for the product lifecycle with tactical daily progress on specific fixes and features facilitates team focus on accomplishing the items most important for success.  The discipline of daily planning does not ensure that the team won’t get side tracked of course because in truth it’s not that simple.