Conduct high-priority product research

Flickr image source: http://tinyurl.com/pmvvurb

To address one of the most critical problem areas for customers using our software platform, I decided to roll up my sleeves and conduct the fieldwork myself.

For many months, we had been recording feedback from our customers, some direct, some indirect around one particular area of the product. Everyone agreed that we had delivered really powerful features - the common challenge was in the setup and configuration. We had made it too complex to use this valuable piece of the product! 

I couldn’t agree more. I knew how hard it was, even for more technical users to configure the tools. I have a deep programming background but even I would struggle trying to ramp up on proprietary schemas with cryptic configuration syntax and poor documentation.

We had been attempting to compensate and even head off frustrated customers by offering to have our own Professional Services team help get customers up and running. But that only served to delay the inevitable as the complaints would then change to “even if you build it for me the first time, I’m not confident I can take it over and maintain it!"

What drove this decision

I had been anticipating a suitable window of time where we could focus on revisiting and rethinking these problems. The teams had been making good progress on some of the pre-requisite components that would be leveraged to rebuild this key feature of our platform. It was time to initiate a round of interviews with customers about how they use the current product, what (if anything) they liked about it and what (again, if anything) they could point to that causes problems for them or their end users.

I wanted to take full advantage of this opportunity to get out of the building, to speak directly to users and reinforce this important research activity with the members of my Product team. Mostly though, I wanted to improve our product and make our customers happy.

The decision: Enlist the help of our User Research expert to coordinate formal interviews with a suitable group of administrators and end users from our active customer base.  

I am fortunate to have a talented resource on our team who has raised the bar around user research for our entire company. She continues to guide us all on the finer points of interviewing users early on around product discovery and later on for product usefulness and usability. With her by my side, I felt very confident that we would get to the crux of the problems and ultimately, be able to prioritize the work to come.

While I was eager to get started and optimistic about what we would learn, I heeded my colleague’s advice and adhered to the plan we made to ensure a favorable outcome.

Plan of attack

It was so tempting to just start writing requirements. But I've been wrong before.

I have used our product internally and I have also demoed it hundreds of times to customers so I felt confident that I knew what was wrong and what would need to be fixed. It was so tempting to just start writing requirements.

But I’ve been wrong before. Let me say that again, I’ve been wrong before. I have felt strongly about how our product should work and went straight to the Engineers with requirements only to find out, after they had spent valuable time implementing the stories that there were no customers lined up to use the new enhancements.

Start with hypotheses and a good prototype

Because I was so familiar with this particular part of our platform, I was able to quickly compose a lengthy list of hypotheses of pain points where I would expect to hear complaints from both heavy and casual users:

• We believe Admins are struggling to initially configure a URL to set up a new instance of [tool] in environments like Salesforce.com.
• We believe end users are frustrated with the number of clicks required to complete the ... process, especially if only one document is necessary.
• We believe Admins are resisting adopting and expanding their use of [tool] because it lacks good error handling, is difficult to test, and has too few options for controlling its behavior for the end user.
• We believe end users struggle with scrolling and otherwise navigating through the different areas of the page, e.g. with long lists of templates or with very long data forms and may find it helpful to track incremental progress as they work through sections of a longer form.
• We believe end users are underwhelmed with the stark layout of the [tool] page, the lack of branding, and the lack of any help text.
• We believe end users struggle with using the [tool] with different browser window sizes, specifically when the buttons move around when the page is resized.
• ... 

I then had the UX team mock up a clickable prototype that addressed some of the primary concerns and that would allow us to better engage with our interviewees.  

Recruit and track participants

To build a list of participants, I first reviewed the customers who were already part of our formal “labs” program (always be recruiting!). Then, I put the word out to our Sales and Professional Services teams to identify other viable customers with whom we could talk. The resulting list was manageable enough for us to track using a shared spreadsheet that included contact information, interview dates, and miscellaneous notes.

Flickr image source: http://tinyurl.com/nomqgdl

Contact Names	Organization	Preferred Phone/Email	Participation	Last Contact Date	Future Participation	Primary Internal Contact	Notes
Nellie Bluth	The Bluth Company	nbluth@thebluths.com	Asked to be included in Fall research initiatives	7/12/15	Also willing to help with...	Maggie Lyes, Acct Mgr	Has been helpful in the past but admits to not being technical

Conduct and record the interviews

When we had accumulated a sufficient list of suitable users, I crafted and sent out an email invite along these lines:

“Hello Vincenzo, I would like to enlist your help for a product research initiative.

I head up the Product team and am leading an active project to learn more about how customers are using our tools. I am reaching out to you because your group is currently using [tool]. I believe you would be able to provide some great feedback on what is and isn’t working well.

If you are interested in participating, the next steps are easy:

1 - Reply to this email with some available interview times over the next 2-3 weeks.
For example, “Tuesday mornings are better”, “tomorrow”, “Wed/Thurs between 3-5pm Pacific”.

2 - Prepare to walk us through how you or your end users use [tool] today

This is a great opportunity to tell us about your successes with [tool] as well as things that would make it easier for you. The conversation should not take more than 45 minutes.”

Not surprisingly, our more fervent users responded immediately. With the others, it sometimes took a little more effort to secure the interviews. We mostly used virtual web meetings to conduct and record the interviews where the customer did most of the driving while we watched.

Our agenda for the interviews followed this path:

1. Show us how you use the product today [50% of the interview time was spent here]
2. As an [administrator, end user], what would you say if anything, are your favorite things about [tool]? [10%]
3. What, if anything causes you or your users problems when using [tool]? [20%]
4. Switching gears, we'd like to show you our ideas for a new design... [20%]

I had an intern transcribe notes from the recordings, putting all the material in a central repository so we could index it properly and share it with the rest of Product and Engineering.

The impact

The customer interviews went smoothly giving me exactly what I had hoped to obtain. There was plenty of validation around our current shortcomings, some surprises about certain attributes that users found valuable, and an abundance of constructive griping. The early prototype seemed to be a hit with users and gave me additional confidence to pursue that path.

I expect to deliver a first round of product improvements in the very next release and will continue to engage these customers to validate our efforts.  Look for more reports from theProductPath around customer research, product validation, and feature prioritization here on PM Decisions.

More articles from our blog PM Decisions

Respond to unhappy customers

Flickr image source: http://tinyurl.com/orb4qg5

To learn more about post-purchase sentiment, I decided to engage with our Customer Success team and become more aware of where our users were struggling.

I will admit that my Product team and I tend to spend more time interviewing and talking with amicable customers. That is not to say that we only approach our happy users; in fact, a fair number of the research-oriented conversations have been tempestuous. Indeed, through our collective research efforts over the past year, we have collected quite a bit of product feedback that would land well on the other side of "needs improvement".

But in this exercise, I wanted to turn my attention specifically to customers who were in peril. And I wanted to go straight to the front lines.

What drove this decision

In addition to what we were learning from the interviews we had been conducting with customers and prospects around new features and enhancements, I also wanted to know more about our product's pain points. And I thought that a great way to do that was to talk with customers who were currently lodging their complaints with our Support team.

The decision: Carve out time to listen to and understand some of the problems customers were having with our product and to help identify ways to address each distinct concern.

In span of a single week, I was able to participate in three separate support cases. I got a chance to hear, in some cases first-hand, from customers who had legitimate complaints about:

1. An unacceptable implementation scenario
2. An (unintentional) product feature gap
3. A grueling Administrator on-boarding experience

These scenarios afforded me with a good cross-section of problems to explore. One was griping about our product's inability to satisfy their complex security problem. Another had caught a change we had made in a recent release that legitimately "broke" one of their use cases. And a third was trudging through our formal training course and was beginning to grasp all that he would ultimately have to learn to support his own company's solution.

Plan of attack

I was intrigued to have three customers with three very different concerns. My process for each was similar however. I spoke with Customer Success person who was interfacing directly with the users, tried my best to assess the particular situation and made sure I understood each customer's own challenge. 

In the end, I helped to resolve each situation but with three very different outcomes.

Scenario 1 - "Fire" a customer for which there was truly no fit

My first conversation revolved around a newer customer who had been planning to go live with their implementation in the next few weeks. In working through their initial project, however, they had determined that they needed a much more sophisticated security scheme and were now struggling with that part of our platform.

It did not take me long to recognize we were at an impasse.

Somewhere along the way, we had clearly misled this particular customer. We had since exhausted all the obvious and even more creative options and I confirmed that we would not be otherwise enhancing the product to support their unique use case.

It did not take me long to recognize we were at an impasse. Looking to quickly resolve the situation, we made the tough decision to rip up the customer's contract and return their money.

Scenario 2 - Escalate a support ticket regarding a product oversight

My next conversation was much different. Here a long-time customer had submitted a complaint with our Support team about a small feature that was removed in a recent product release. It was clear to me that we screwed up.

It was clear to me that we had screwed up.

After hearing their scenario, I agreed and admitted that we had inadvertently taken away a small piece of functionality that they had been relying on. I recommended that we escalate the Support ticket to trigger a feature enhancement request that would bring back comparable functionality to help restore their solution.

Scenario 3 - Meet face-to-face with an overwrought Administrator

And finally, toward the end of the week, I was made aware of another new customer who had been floundering a bit. The designated "administrator" at this company, who was in charge of making it all work was currently enrolled in our (highly recommended) training class to learn the ins and outs of our software but was laboring under the breadth and depth of the course material.

Flickr image source: http://tinyurl.com/qyuf6pa

In truth, the original implementation project was poorly scoped and was running over budget. It was clear that more time would be needed to complete the work. But the Administrator was becoming even more unsure about his ability to ultimately support his own company's users when the solution was finally deployed.

I scheduled an hour meeting with him after the training class (we actually talked for more than 90 minutes) and listened to his concerns. After some healthy venting, he ultimately agreed that none of his immediate doubts were tied to the platform itself. Instead we decided to revisit the original statement of work and work with Sales and Professional Services to properly expand the scope of the project to fit his organization's needs.

The impact

Looking back, I am not sure if my products are better off as a result of these interactions. At the end of the week, I had been engaged in three unique customer scenarios and delivered three different resolutions:

1. Defend the product, even if it meant losing revenue and risking our reputation
2. Admit our product mistakes and try to earn back the customer's trust
3. Reset a (new) customer's product expectations and help them find a successful path forward

Look for more reports from theProductPath around customer research, product validation, and voice of the customer here on PM Decisions.

More articles from our blog PM Decisions

Sit with customers for product training

Flickr image source: http://tinyurl.com/neccbh5

In yet another attempt to get out of the building and sit face to face with my customers, I decided to grab a seat in the next customer training session.

Product Managers, of any rank, need to get to know their end users. You don't get to hide behind a fancy senior-type title to avoid the difficult and often humbling experience of interacting with the people who buy and use your products.

But it can be more challenging for the Product Head Honcho to carve off blocks of time to sit with customers because the role has so many other responsibilities.

What drove this decision

In the back of my mind, I knew it had been too long since I had had any real interaction with our users. For months, I had been relying on solid, but second-hand input from my Product team to help drive roadmap decisions but I very much wanted to supplement that with my own data points.

Some weeks back I learned that the company had scheduled the next multi-day training class for customers and partners. I knew that would be a decent opportunity to step away from the office and spend some quality time with my target audience.

The decision: Spend most of the class in listen-only mode while also weaving in some interactive, product-focused discussions. 

Our customer training course is a week long affair and operates on a fairly tight schedule because of the range of functionality we cover to address a rather broad set of use cases. As such, I would not be able to carve off big blocks of time to do proper customer interviews. So rather than hijack the agenda, I looked for other windows of time for both formal and informal interactions with the attendees.

I made it my goal to bring back new product insights to my team and to learn as much as I could about both our existing and future product direction.

Plan of attack

You don't get to hide behind a fancy senior-type title to avoid the difficult and often humbling experience of interacting with the people who buy and use your products.

As I mentioned, the training agenda is tight so I would be squeezing in opportunities here and there to cover my own topics. To kick things off, I gave the standard welcome speech on the morning of the first day and wove in my parallel agenda as we covered the week's schedule.

I teased the audience by inviting them to attend a "working lunch" where I would deliver a live overview of new enhancements that were part of the major release that had just been pushed the week before.

I also proposed that we gather before class on one of the days to preview some of the exciting ideas we were brewing up in our Research Lab. This would be a unique opportunity for me to pick their collective brain and for them to help steer the products themselves.

And finally, I encouraged anyone looking for 1 on 1 time to track me down during the regular breaks to talk about any specific topics.

Emphasize the value of feedback from customers

View fullsize

Product roadmaps must balance inputs from many sources. (Click to enlarge)

In every interaction, I tried to stress how important it was for me and my team to hear from our users. I talked about the different options they could utilize for passing back their concerns, suggestions, and praise (ha!).

I was careful, however, not to set the expectation that we would act on every input. I showed a product-centric chart that I use to educate/remind both external and internal audiences of the complications of owning a product - specifically that the inputs are many and the available resources are finite. 

Spotlight product updates based on voice of the customer

To reinforce those messages, I queued up some of the new product features and enhancements we had delivered over the past few releases that were largely driven by customer feedback. I talked about how early interviews had revealed common pain points across customer implementations. And I showed how, through constant validation with end users, we had been able to advance the product to address their requirements.

Recruit end users and administrators for future R&D

Always be recruiting. That could be the slogan for our research team - and they never let me forget it. So I also put in a few plugs for our ongoing R&D initiatives. Passing out business cards is easy but somewhat impersonal so I also followed up with an email to all the participants.

The impact

I did gather some good product feedback from the group, some of it unsolicited and some of it through more formal discussions. I would recommend opportunities like this to other Product Managers looking to spend quality time with a captive audience.

The class participants seemed appreciative as well. They had positive reactions to the connections I made between customer feedback and product innovation. There also seemed to value having a direct line to the company's Head of Products, if only for a short period of time.

Look for more reports from theProductPath around customer research, customer development, and voice of the customer here on PM Decisions.

More articles from our blog PM Decisions

Clarify win-loss speculation with post-mortem interviews

Flickr image source: http://tinyurl.com/ngyurwt

After yet another desperate claim from an exasperated Sales team that we were losing deals because of presumed product gaps, I decided that I needed hear it first hand from the customers.

I look forward to the days when I can sit with our Sales team on a regular basis (at least quarterly) and formally walk through our wins and losses. I say this somewhat selfishly because I have seen our company overreact repeatedly to lost deals. There is a tendency to find scapegoats and Product is often an easy target.

I know we have sufficient features with clear benefits to close new deals (our win rate is actually pretty high) but it still stings when a customer chooses a competitor. Nobody likes to lose but we need to reflect on these events in a productive way. We need to be truthful with ourselves and learn from our losses.

What drove this decision

A battle was already brewing between Sales and Product around a set of "must-have features" that had been distracting me from the real roadmap priorities.

In fact, I had been cornered a number of times over the past few months, typically by a Sales manager stomping around the office, still sore after getting the bad news that we lost another opportunity.

But warning bells were going off for me after hearing what seemed like unfounded claims that the deal fell apart because our product fell short in a certain area. I was especially curious about one deal in particular which we apparently lost to a couple of vendors with whom we never compete.

Something didn't make sense about these claims and I wanted to reconcile my own hunches with those coming out of Sales.

The decision: Schedule discussions with the lost prospects to learn more about their exact decision criteria.

The Sales team has been winning and losing deals for a long time but aside from our Reps recording one of a dozen pre-defined "reasons" in our CRM, the team had never spent any cycles capturing the details of the sale - and certainly had not been sharing the broader stories in a broader venue.

Our best opportunity to circle back with a lost prospect would have to be soon after they told the bad news. We had 2 such losses in the past 2 weeks and I scrambled with the Sales team to set up separate calls with each prospect to get the rest of the story, from their own mouths.  

Plan of attack

Flickr image source: http://tinyurl.com/od5e5na

My suspicion in both cases was that my Sales team had misinterpreted the customer's needs. In both cases, our folks had assumed that it had been a particular feature or set of related features that our competitor offers that had been the deciding factor. I was skeptical, but mostly because I didn't think our Sales team had a complete grasp of the other offering and were being hasty to find a scapegoat.

We scheduled conversations with each prospect and I had the Rep and their Sales manager sit in, mostly to listen. I shared my hypotheses with the Sales folks up front - specifically that I thought we would ultimately get feedback from the customer that was different from the conclusions they had drawn.

I also made it clear to them that I was motivated by a desire to learn and had no intention to lead our witnesses. 

Interview 1st prospect about competitor's tool

We had been hearing more and more about one particular competitor product in our sales cycles. They (the competitor) knew we didn't have an answer to it and wisely used their own product as a land mine to trip us up. I don't want to take anything away from our competitor but it was clear that they were intentionally guiding prospects to focus on this tool even when the prospect wasn't struggling with the set of problems it solved.

I've seen the tool and it does provide some attractive features. Until recently, we had been assuming that 1 feature in particular was winning over prospects. But the deal notes from our own Sales Rep on this opportunity pointed to something else.

We learned that our assumptions were wrong - the customer was struggling with a completely different problem.

In a 20-minute conversation with the prospect, we walked through their decision process and ultimately came to the competitor's offering. When prompted to identify the actual pain points and how well the competitor's tool matched up with those pain points, we learned that our assumptions were wrong - the customer was struggling with a completely different problem.

After thanking the prospect, I reviewed the outcome of the call, as gently as I could, with the Sales team to make sure they understood the real criteria of the customer's decision. The new information was indeed valuable and we would have to incorporate the findings into our own product strategy but it was also important to set expectations appropriately inside the company so as not to unnecessarily exaggerate our presumed product gaps. 

Interview 2nd prospect about broader needs

The second opportunity was apparently lost to vendors that we never see in our typical sales cycle. That seemed to me to point to a fundamental misunderstanding about what problems that customer is looking to solve.

We ran through a similar post-mortem conversation with this prospect who was all too happy to share their issues again. I find it easy to start conversations with decision makers around their pain and struggles. And even though our Sales team had just spent weeks courting them, they approached this new conversation with our Product team with unexpected enthusiasm.

Our Sales team had clearly wasted way too many cycles chasing an unqualified opportunity AND had drawn unnecessary attention to a presumed product gap.

Since this customer had not yet made a final decision, we steered the discussion to what had separated us from the remaining vendors. What I heard was at the same time validating and frustrating. The customer had legitimate needs but ones that would never be solved by the type of solution we had to offer.

The good news for me was that this lost deal was not going to impact our own ongoing product decisions. The bad news was that our Sales team had clearly wasted way too many cycles chasing an unqualified opportunity AND had drawn unnecessary attention to a presumed product gap.

The impact

Both prospects were not only willing to share with us but actually quite impressed that we would take the time to learn from our lost deals. I would like to think that this customer feedback will only accelerate our plans to formalize our win-loss analysis discussions in the months ahead.

I'm also hopeful that our Sales team will start to acknowledge that they sometimes misread the prospect's ultimate decision and will refrain from rushing to hasty conclusions. Perhaps only time and ultimately, more losses will tell.

Look for more reports from theProductPath around voice of the customer, competitive analysis, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Cut down the scope of the initial product by 20%

Flickr image source: http://tinyurl.com/pg4zl82

After receiving push back from users in the first rounds of testing, this startup decided to eliminate a significant portion of its product offering.

For the past year, I have been observing the early stages of new business, started here in Chicago. The technical co-founder, a close friend, has also been serving as the Head of Product, not uncommon for small companies. I have been keenly interested to watch how this team would bring their vision to market and all the twists and turns that path would take.

One interesting development occurred after they put their initial version of the product in front of their target users. The feedback was immediate and in my opinion, quite sobering. The team would seem to have gone too far in one direction and was now facing a critical decision to scale back the initial scope of its product.   

What drove this decision

“This is too hard. I don’t want to create more work for myself or my client.”

— Early prospects

The originally envisioned product was intended to utilize a 3-step process. Users would complete a high-level questionnaire followed by a more detailed assessment to produce a curated product catalog where they could then make purchases in a familiar e-commerce scenario.

After developing a reasonable first pass at each of these components, the team put the product in front of a sample set of target users. The feedback was prompt and to the point: this is too hard.

The team had to make a change.

The decision: Drop an entire section of the user workflow

The (initial) users had spoken. The workflow had to change. It had to be simpler to complete. This startup team needed to step back and review the customer flow.

Plan of attack

The team ultimately decided to refactor the 3 step process and eliminate 1 of the questionnaires. After that, it would be time to test again:

• How would the new process change the results?
• Was there still a clear path to the purchase?
• What would the users find challenging about the new workflow?

Rethink the customer flow

The refactoring exercise began by decomposing the workflow process into finer grained steps, then exploring alternative paths for leading the user to the product registry at the end. The team focused on keeping what was needed most and trimming away the rest.

Redeploy the process with 1 fewer components

Having established the revised flow, the team proceeded to put the pieces back together to create a more streamlined activity for the users. The objective: a simpler process with fewer steps that produced the desired outcome.

Image source: https://www.flickr.com/photos/mmetcalfe/3874486791

Retest with users

Armed with an updated and improved product, the team scheduled the next round of user testing to validate their work.

The impact

Ultimately the team verified that their users could successfully complete the process without the extra steps. It takes courage to put an unfinished product in front of your customers and even more guts to go back to the drawing board when you get frank criticism.

Removing working code from a brand new product can be hard, especially if you look at the work required to build that code as having been wasteful. But I would argue that learning early leads to less waste. I applaud the startup team and encourage all product-minded people to follow their lead.

Look for more reports from theProductPath around product validation, feature prioritization and voice of the customer here on PM Decisions.

More articles from our blog PM Decisions

Create an in-person event to engage your customers

Image source: https://www.flickr.com/photos/highwaysagency/5997001123/

In realizing I had not spoken directly with our customers in some time, I decided it was time to get out of the building.

With a major software release right around the corner and being short a Product Manager due to a recent exit, the team was justifiably busy. There was plenty to do with making sure the upcoming deployment went smoothly while also firming up our plans for the very next release. And then there were the myriad other tasks that were on our plate, making it easy to rationalize that there simply was no time in the schedule to step away to talk to our customers.

But let's be honest here. By not making the time to engage your customers, all your other product plans are likely to fail.

What drove this decision

I was starting to get that gnaw in my stomach, the one that comes from making too many uninformed decisions. Because, no matter how confident you may be in setting the direction of your product(s), there is nothing more validating than getting direct feedback from your customer base.

Our Product team had been fairly diligent about reaching out to our users on a regular basis but many of those conversations are virtual and there is often a communication gap with phone calls and web-based meetings. I was eager to get some good face-to-face interaction with our target customers, to hear what they liked about our software, to learn what we could do to help them accomplish more, and to share where we were headed with our new roadmap. 

Image source: https://www.flickr.com/photos/mdd/9890924226

The decision: Leave the building (and the city) and spend some quality face time with a group of customers representing a good cross section of our users. 

As hesitant as I was about disappearing from the office for a few days, I knew the in-person discussions would more than compensate. And the plan for this particular trip was to spend a half-day with more than just 1 or 2 customers, so I knew I would return with a good assortment of responses to share with the team.

Plan of attack

Our Customer Success team is in the (good) habit of reaching out to new and existing customers in order to follow up with ongoing implementation initiatives and also to promote the Art of the Possible. We decided to make this event a twofer, extending their standard agenda with a short, product-specific program.

Build Simple Customer Profiles

Before "leaving the building", the first order of business was to gather some intel about the attendees with whom I would be meeting. Together with our Sales and Professional Services teams, I put together some brief customer profiles, paying specific attention to their specific use case and, as a crude gauge of their comfort level with the product, how long they had been users of our system.

This gave me some good, initial context for the level of discussion I would likely be having and helped me refine the scope of the topics I could cover. 

Create an Engaging Presentation

I know that very few people look forward to watching a PowerPoint presentation but, when done well, a good slide deck can be an ideal way to communicate ideas with a large audience.

For this event, I pulled together a series of slides that I thought would keep their attention and, more specifically, prompt some honest discussion among the group. For example, I included in the deck:

• A high-level, vendor's perspective of their business problem, showing how the company views their particular customer scenarios and intended to trigger dialog around exceptions and edge cases;
• Annotated screenshots of recently-introduced product features that they may not have had a chance to play with but would take too much time to demo completely, meant to spark conversation around additional exploration and use of the product;
• And a 1-page Product Roadmap that communicated, in broad strokes and without specific dates, the priority of particular product initiatives related to their use cases, designed to stimulate feedback and confirm we were on the right track. 

Days before the event, I reviewed the material with my team, incorporating some great, internal feedback while also rehearsing the presentation flow.

Demo, Survey, Preview, Recruit

There was a lot to squeeze into the time slot we had carved out for my Product talk. I wanted to promote the current state of the product and explain how and where we were looking to make enhancements. I had brought along some early, high fidelity prototypes in case we hit on a particularly popular or sensitive topic. I also was hoping to conduct a brief survey to get feedback on a number of our product roadmap intentions. And finally, I had hoped to recruit some of the customers into our more formal "labs" program so we could follow up with more intense analysis.

Other than a few weather-related, last minute cancellations, the meeting went off without a hitch. The participants seemed pleased with having direct access to the Product organization and appreciated the brief glimpse into the company's product strategy. Many of them have since enrolled in the more structured labs program and have indicated a strong preference to stay engaged with us.

Share Results With the Product Team

I returned to the office the next week eager to review the notes with the Product team. And while it seems there is never sufficient time to fully digest results of customer interviews and surveys, I was able to share a synopsis of the event and fold much of the feedback into our (still crude) research database.  

The impact

The good news is that the majority of the feedback validated our current product plans, at least for the next few major releases. It is certainly helpful to hear from your own customers that the product is indeed solving their needs. There were some familiar "hot spots" and valid complaints from the group and this has led to some re-prioritization work on our side that might not have been prompted by an interview with a single customer.

I strongly suspect there will be more such events in our future and that, as we continue to strengthen our outreach efforts, we will find it increasingly easier to get out of the building.   

Look for more reports from theProductPath around customer research, product validation, and voice of the customer here on PM Decisions.

More articles from our blog PM Decisions