Build the prototype to aid in new product discovery
In recognizing that we were finally in a position to start gathering real requirements from a prime new customer, I decided to move forward with building a prototype for a new product offering.
The Product Decision: Complete a working prototype that we could use to drive productive conversations with customers around requirements.
Flickr image source: http://tinyurl.com/pfyguao
In recognizing that we were finally in a position to start gathering real requirements from a prime new customer, I decided to move forward with building a prototype for a new product offering.
The Product team had known for some time that we had a legitimate gap in our product portfolio around an MS Office 365 Plug-In but we were not overly anxious as it was clear that the gap was not preventing the company from winning new deals. Even though our main competitor would regularly raise the issue with prospects during the sales cycle, drawing attention to our "deficiency", it had never cost us a sale.
The MS Office 365 Plug-In saga continues to unfold...
You can review the entire story through my past Product Decisions:
HEAD OFF A NEW PRODUCT IDEA BEFORE IT GAINS ANY MORE STEAM
CLARIFY WIN-LOSS SPECULATION WITH POST-MORTEM INTERVIEWS
BUILD A QUICK PROOF OF CONCEPT
From the beginning, when this "urgent need" was first identified, I had been steadily pushing back on internal stakeholders (see sidebar). I knew we didn't have the available resources or bandwidth to tackle this and without a line of customers outside my "product door" clamouring to have the new feature, I was hesitant to even start conversations around the Plug-In.
What drove this decision
In the previous quarter, we had signed our biggest customer in the company's history and, in our lengthy discussions with them around their needs, we had identified the (missing) Plug-In as a key, must-have feature.
This one customer, when fully deployed, could have more than 2,000 people using the new Plug-In. Based on those numbers, it seemed reasonable to me that we now had a decent base of users from which we could start to gather some useful insights.
The decision: Complete a working prototype that we could use to drive productive conversations with customers around requirements
I was eager to start talking with and observing real users in the field but I didn't want to do that using the low fidelity and crudely fashioned proof-of-concept we had completed a few months back. It was time to build and start testing with a real, functioning prototype.
Plan of attack
We were still very early in the product cycle for this Plug-In and there was no pressure to cut corners or skip steps in our product discovery process. I wanted to make sure we used a disciplined approach.
In this first phase, we would create a prototype that would give our Tech team more confidence in what it would ultimately take to develop and support such an app AND that would give the Product Team enough material to have meaningful discussions with the first round of users.
Vet the feasibility of our technical approach with Engineering
Flickr image source: http://tinyurl.com/p65wgqb
I had some solid ideas for how to create an initial version of the Plug-In though it was fair to say that we would be forging into unfamiliar territory. The Tech team had never developed this kind of app but we knew we would be getting support from our friends at Microsoft who is one of our key technology partners.
The first step in building the prototype was making sure our team could nail down some of the technology challenges that we would face. For example, high on our list were questions about user authentication, API access, and deployment of the app to customers through Microsoft's "online store".
So, over the course of a few weeks, the team completed a functioning prototype that addressed these areas of concern. Now, more confident that we had cleared the most immediate technical hurdles, I proceeded with getting some internal validation.
Share the prototype with stakeholders inside the company
I very much wanted to show the prototype to our Sales Engineers. They had always been good product collaborators and certainly understood the broad use case for the Plug-In. I set up a meeting with them and the Product team and with the Engineers to get and record some early usability feedback.
On the way to that meeting, I made a small detour to give a brief demonstration to our CEO as a courtesy “first look". He had taken a keen interest in this initiative and had been stalking me for many weeks. And even though we had only addressed the most simple use case in this iteration, he was very impressed with our rapid progress. My only regret was letting an Engineer run the demo - who uses superheroes for their sample data? Ha!
I should have known not to let an Engineer run the demo - who uses superheroes for their sample data?
We then sat with the Sales Engineers and reviewed our current hypotheses with them. They see much more front-line action with prospects in the sales cycle and helped validate our approach, often tying back to their deals from the past weeks and months.
I then had each of them install the Plug-In on their own machines to test it out. The response was overwhelmingly positive and we could see them already thinking about how they might adjust their standard demo scenarios to incorporate this new component.
One of them suggested they start using the Plug-In immediately to help them with one of their own team activities and I offered to check back in with them in a few weeks to see how it worked for that additional use case.
Show it to the technology vendor on whose platform our prototype was built
We had invited representatives from our partner Microsoft into our office for a high-level meeting to talk about Office 365 integration among other things. The timing of their visit provided a perfect opportunity for a prototype demo and to show what we had achieved in the past few weeks, with some help from their own technical folks.
After setting up the customer scenario with the group, we walked them through the working prototype and talked through some of the challenges we had worked through to get to this point. The Microsoft team provided additional validation around our approach for the Plug-In and gave us some pointers for how we could move forward. Our remaining questions were captured and would be carried back to their teams to help get us the answers we would need before rolling this out, even to beta customers.
In the end, I was pleased to know that our partner was ready to help us with next steps. They also expressed interest in the upcoming deployment with our new customer as it would provide a great case study for both us and them.
The impact
With the Engineering team, I was able to work through a few of the big technical unknowns to build a working version of the Plug-In. By meeting with and showing off the Plug-In to a few internal resources, we were able to get some early, but solid validation. And in reviewing the finished work with the vendor on whose platform we had built the Plug-In, we confirmed that we were on the right track in how we were going to deploy and support the new product.
But none of this would be worth anything if we didn’t immediately start validating the Plug-In with actual users. That work would likely start the very next week and is lining up to be the next chapter in this series.
Look for more reports from theProductPath around product validation, feasibility, and product investments here on PM Decisions.
More articles from our blog PM Decisions
Sit with customers for product training
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.
The Product Decision: Spend most of the class in listen-only mode but also weave in more interactive, product-focused discussions.
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
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
Create an in-person event to engage your customers
In realizing I had not spoken directly with our customers in some time, I decided it was time to get out of the building.
The Product Decision: Leave the building (and the city) and spend some quality face time with a group of customers who represented a good cross section of our users.
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
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.
The Product 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.