Mining the Support Organization for Product Roadmap Data

sign-1238534

The product roadmap that is communicated throughout the organization is actually the result of considerable research that includes:

  • Customer feedback
  • Internal factors
  • External factors (using the STEP model – Social, Technological, Economic, and Political trends are all analyzed)
  • Competitive analysis
  • Sales analysis (win-loss)
  • Product analysis (a subjective and objective checkpoint of the product in its current state)

It is the last item, Product Analysis, where mining your technical support database can lead to some enlightening and useful information to drive the future direction of the product. In the past, I have mined this empirical data as a measurable means to understand the strengths and weaknesses of the product. This comes in three forms:

  1. Customer-requested features by function
  2. Customer-reported bugs by function
  3. Support incidents by function

For each of these three components, I have found it most useful to have this data grouped by functional category. This provides a measure of what areas of the product customers find lacking (feature requests ) or problematic (bugs and support incidents). For one analysis that I did, the same two functional areas of the product bubbled right to the top for having the most feature requests, reported bugs and overall support incidents. Recommendations from a Product Manager are best when the are backed by data – what better “ammo” to have to convince anyone of where the focus needs to be.

Pulling and massaging this data is dependent on the solution that technical support uses, however, it is most likely to be there in some shape or form for the taking. Once you have created a process for assembling the information subsequent updates on a quarterly or annual basis becomes easier and allows for comparison from past analysis – for example do support incidents or bugs routinely come from the same functional component of the product. If so, then a problem still exists and warrants an action plan.

This has an added benefit of building bridges and good relationships with the technical support organization so they feel empowered and part of the team. In other words, as the Product Manager you will be exhibiting a sound cross-functional leadership role.

Does your phone buzz you to distraction?

Back when smart phones were beyond the early adopters and into the pragmatist stage (thank you Geoffrey Moore and the technology adoption lifecycle introduced in Crossing the Chasm) I was sitting in my Director’s office having a 1:1 meeting.  Our phones kept vibrating for every incoming email and since we were on many of the same distributions, oftentimes the phones vibrated simultaneously – it was a cacophony of sounds and vibrations.  Right then we decided to shut off our email notifications (on our trusty state-of-the-art Blackberry’s no less).  I have never looked back.

The ability to multitask seems to be a badge of honor in today’s fast-paced work environment but is it more productive?  Not really, and now this new research suggests that just hearing your phone buzz hurts your productivity.  In a similar Harvard Business Review report, digital distraction was christened, “the defining problem of today’s workplace,” – and it starts and ends with our phones.  Moreover let us not forget to mention the impact of notifications with people’s driving behavior – how many times do you see people sitting at a green light because they are focused on their phone and not the green light?

So take heart, shut down your notifications, don’t feel guilty about and be more productive!

Never invite sales people to a meeting

Mark Officer:

Excellent blog! There is another danger in inviting sales people to a meeting. Feature requests that come from sales are often based on their opportunities and their financial gain if a sale in their forecast closes. Product managers need to be more holistic in treating feature requests. This is not to say that it may my be a worthy feature but it does require additional validation and evaluation.

Originally posted on Under10 Consulting Steve Johnson:

clock

In 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 458 more words

How to Conduct a SWOT Analysis the Right Way

Previously I posted a blog on my version of a SWOT Analysis Workflow.  I summarized this article into this Slideshare presentation How to Conduct a SWOT Analysis the Right Way.

I did this for two main reasons, namely to emphasize that a SWOT analysis needs to be based on research which is why the situational analysis is a prerequisite, and secondly the SWOT diagram that everyone is familiar with, while is it a great visual tool it needs to be followed up with a set of recommendations (the roadmap).

The importance of listening (and always asking questions)

When talking with customers, it is not enough to take their feature requests at face value.  What they ask for may not necessarily be what they want. Here is an example of a conversation I had with a supervisor of data entry users for a transaction-based processing solution:

User: We need a Back button (Editor’s note: this is not a web-based application)

Product Manager: Seems simple enough, do you envision the Back button being used frequently?

User: Oh yes!  Often times we need to go back and reference or correct an order that we worked on up to two hours ago.  We move through the orders so fast we can’t always remember the order number or customer so a search is not an option, so we need to go back through our previous orders.

Product Manager: Okay, I understand the problem but rather than a back button, how about having the ability to easily show the history and the user can see all the previous orders and go directly to that order.

By asking one more question – digging deeper into the why – I was able to fully understand the pain better and offer a better alternative than a simple Back button. This is similar to the Chrome and Firefox feature that allows you to see the history by holding down or right-clicking the Back button.  It is easy to see how clicking through the Back button in a linear fashion is inefficient when the page or order you need was more than a few clicks back.  I’m sure this is why the Show History option was implemented in these browsers.

In a similar vein, but all together a different market, I was reading my August 2015 issue of Bicycling magazine, and in particular an article titled “How to get $h!t Done” which is about Lisa Nutter, the First Lady of Philadelphia. On top of being a serious cyclist, the First Lady is a huge advocate to make riding more accessible.  In the article she states:

The language used to describe bike infrastructure is becoming a barrier to talking about what people really desire.  People aren’t saying, “We want bike lanes.”  They’re saying, “We want safe ways to get here and there.”  We have to listen to the way people talk about cycling and engage them where they are, not where we want them to be.

I completely agree with what the First Lady is saying, however, I think that most people do indeed offer specifics on what they think the right solution would be, in this case bike paths.  Product Managers need to understand what they really want which is a safe way to ride in city streets.  Bike paths may be part of the solution but not necessarily all of it or maybe not even the highest priority, maybe it means additional or improved crosswalks.

So the takeaway here is very simple, always dig into the problem, keep asking questions, discover the pain and in doing so you will find what the best solution is.

 

Book Review: Writing Effective Use Cases

Writing Effective Use Cases Front Cover Alistair Cockburn is a well-renowned expert on agile development and use cases; his book Writing Effective Use Cases is a “must read” for all product managers.  There are professional books that you read, then put aside and sometimes you might refer to them.  Other books become part of your core reference library, never far from your reach, dog-eared from frequent reading, and filled with highlights and underlines – this is one of those books. 

For someone who has never written a use case, this is an excellent starting point, covering all you need to know about use cases to be successful.  For those that have written use cases, I am confident that you will find many new valuable nuggets of information that will help you in your job.  The book is manageable in length (270 pages including appendices and index) and very practical with many examples of uses cases throughout (including examples of bad ones).  The most valuable aspect to the book is Cockburn’s professional advice and tidbits that he sprinkles throughout the book.  Anyone who is familiar with Alistair Cockburn’s work knows that he has a great deal of experience, and it shows in this book.  This book is short in theory and long in real-world examples.

Cockburn refers to use cases as “scaffolding” that connects various pieces of the project, which is very true.  Use cases are crossed linked to requirements, user interface designs and test plans, creating a traceability matrix throughout the lifecycle of the project.  Cockburn dedicates a chapter to how use cases fit in the overall process.  Managing the entire body of use cases is just as important as writing them.

A big part of any product manager’s job is time management, and Cockburn addresses this in the book.  It is not feasible to write detailed use cases right from the start, and it certainly cannot be done for all of the potential uses cases.  Cockburn stresses the importance of “warming up” with use case briefs or narratives, and then working towards more detailed, fully dressed use cases.

I like how Cockburn distinguishes between requirements and use cases – this is an important concept for product managers to understand.  In short, use cases really are requirements.  Properly written, use cases describe the behavioral requirements.  However, with that said, use cases do not deal with all requirements such as the non-functional ones (external interfaces, performance criteria, documentation standards, etc.).

For those product managers that already have their own format or preferred method for use cases, Cockburn provides many examples of different use case styles.  He is quite flexible in this regard, understanding that use cases are, “fundamentally an exercise in writing prose essays, with all the difficulties in articulating good that comes with prose writing in general”.  What Cockburn is very insistent about is that the use cases must be easy to read, short and clear for all stakeholders to understand.

There are other excellent books on use cases (Use Case Modeling by Bittner and Spence is one I would also recommend), however, at the end of the day, a product manager needs to adopt one standard and run with it.  Cockburn’s book fits this bill and more.  I would highly recommend this book for new or experienced product managers.   

Distinctive Competence

Steve Jobs was recently named the CEO of the Decade by Fortune magazine.  Could there be any other choice?  As the article notes, “in the past 10 years alone he has radically and lucratively reordered three markets – music, movies, and mobile telephones – and his impact on his original industry, computing, has only grown”.  Much is talked about a company having a distinctive competence – those critical assets that uniquely define and sustain a company’s being – in another words, what do they do better than anyone else.  With Apple it is very clear what their distinctive competence is; they create the most well-designed, user-friendly products that are like no other in the market.  Nancy F. Koehn writes in her article on Jobs, His Legacy:

People who work with Jobs talk about his maniacal attention to the smallest design detail. For Jobs, working in a world of engineers who are focused on the power of technology, this paradigm has never been enough. Yes, his products must be functional and fast. But they must also be beautiful.

Another example is Southwest Airlines.  Southwest has a customer-focused, low-cost operational efficiency that uniquely sets them apart from their competitors.  And now for the final question…can you quickly and succinctly describe the distinctive competence of your company?