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
Practice humility in product pursuits
In recognizing that the string of recent product successes had (perhaps!) inflated my ego and that that might likely affect my judgment, I decided to devote some time to more sobering aspects of being a Product Manager.
The Product Decision: Balance out all the congratulatory feedback and even my own eternal optimism by purposefully exploring activities that would knock me down a notch.
Flickr image source: http://tinyurl.com/od9nlno
In recognizing that the string of recent product successes had (perhaps!) inflated my ego and that that might likely affect my judgment, I decided to devote some time to more sobering aspects of being a Product Manager.
It is easy to get swept up in your team's triumphs, to celebrate (even minor) victories, and to take excessive pleasure in the praise others shower on you when times are good. I am as guilty as anyone of basking in the glow of success. Hitting your goals is satisfying indeed and it is tempting to linger there awhile in that satisfaction.
But it can affect your judgment if you get too caught up in your own hype. I was starting to feel like that was happening to me and I wanted to course correct before I began making poor product decisions. Surely there were some facets of my job or details of the product that were not going so well. I wanted to make sure I wasn't ignoring or just glossing over them. One careless misstep could effectively evaporate all the admiration.
What drove this decision
Credibility is crucial in this role. Product Managers must find a way make forward progress with little to no authority and to do that effectively, we must establish ourselves as capable decision makers. The challenge, of course, is that it takes much longer to build credibility than it does to lose it.
I have found that it is often a long march to establish good standing for yourself in the organization. But you can't get there - or hope to stay there long - if you misrepresent yourself by glossing over the many mistakes you make along the way. You have to acknowledge failures to your stakeholders, to your teams and to yourself.
I did not want to lose any of the forward progress I had made and that meant coming down out of the clouds and remind myself that I was still fallible.
The decision: Balance out all the congratulatory feedback and even my own eternal optimism by purposefully exploring activities that would knock me down a notch.
It seemed to me that a good way to knock myself down from the pedestal would be to engage in the kind of activities where there was no actual way to win. I would, therefore, seek out situations that would test my confidence but where the outcomes were not likely to be favorable for me.
Plan of attack
I found good opportunities to help me reset my ego. During this particular week, I tried out some new ideas that would serve up some humility. I think part of what made these exercises effective for me was that they were somewhat disconnected from my role in the organization. I did intentionally seek out product-related activities, but I would not be taking advantage of my job title to affect the respective outcomes.
Taking a turn at being the interviewee
I volunteered to help a colleague who was running a set of user tests for a mobile application. Specifically, he wanted to interview me as a target user of the app. His product initiative was unrelated to my company which meant less personal risk for me. In fact, I convinced myself that, should there be any missteps, my blunders would only be exposed to one other person.
And boy did I have some blunders! Well, technically, it is hard to say that you can get anything wrong in a usability test. As my colleague reminded me, "we are testing the app, not you." I have used that exact phrase in trying to set proper expectations when leading my own experiments, but it is hard to shake the feeling that, as an interviewee, you're not performing adequately.
At one point in the exercise, I thought I had successfully completed the task although it took me longer than I thought it should have. Must be the app I thought. Then, when I was politely informed that I actually had NOT accomplished the task, I was truly embarrassed.
when I was politely informed that I actually had NOT accomplished the task, I was truly embarrassed.
Being on the other side of the table helped me better understand the anxiety that comes with being interviewed. In the long run, this experience will undoubtedly make me a better interviewer, but I will admit that it had the sobering effect that I was looking for.
Reeling from a wave of negative customer feedback
In this same week, I had started to receive some strong reactions from our customers about a recent feature overhaul and none of it was positive. I can't think of anything much more humbling to a Product Manager than hearing that you may have got it wrong: "Can we just go back to the way it was before?"
The feedback was being collected by and funneled through our internal Customer Success team and we took it very seriously. Of course, my instinct, shared by the entire Product team, was to talk directly to the customer. We had, in fact, been doing that throughout the entire product cycle and had already incorporated earlier feedback into the feature through incremental releases.
"Can we just go back to the way it was before?"
Immediately, we went back to review our notes from these previous conversations which included several sessions with one of the customers who was now griping the loudest. I will admit that it is difficult to keep a cool head when intense emotions are involved.
I found this to be the perfect opportunity to revisit my convictions as a Product Manager, to reflect on how much better I still needed to be, and to remind myself how this particular job really never gets easier.
Proceed over a panel in a roomful of peers
And just to pile on even more, I also volunteered to participate as a moderator in a panel discussion for a group of Product Managers from the local community. I had never been a panel moderator and had never worked with this organization or its members.
Eleanor Roosevelt is credited with saying "Do one thing every day that scares you." Well if you are short on ideas, let me suggest trying your hand at moderating a panel of experts, most of whom are far more experienced than you, and guiding the conversation for a roomful of practitioners in your field.
The impact
Flickr image source: http://tinyurl.com/ph3qp6j
I certainly felt the impact from each of the activities. Any one of them might have been sufficient but combining them all in a single week certainly helped me achieve my goal. And even if you're not working toward the exact same objectives, I can still recommend following some of these pursuits:
- Literally put yourself in your buyer's/user's shoes to help you better develop empathy
- Prepare yourself and your teams for confronting product mistakes so you will know how to move forward
- Do something that scares you, especially around your peers
Look for more reports from theProductPath around product culture, credibility, and the PM role here on PM Decisions.
More articles from our blog PM Decisions
Sync up with Product Marketing
Over the past weeks, I had lost touch with my colleagues in Marketing, so I decided to take advantage of some mutual schedule alignment and catch up with our Product Marketing Manager.
The Product Decision: Regroup with my counterpart in Product Marketing to get our collective and connected plans in order.
Flickr image source: http://tinyurl.com/nwkerlx
Over the past weeks, I had lost touch with my colleagues in Marketing, so I decided to take advantage of some mutual schedule alignment and catch up with our Product Marketing Manager.
“The product marketing team member is responsible for telling the world about the product, managing the external-facing product launch, providing tools for the sales channel to market and sell the product, and for leading key programs such as online marketing campaigns and influencer marketing programs.”
On at least one previous occasion, I have mentioned how delightful it is to have a genuine Product Marketing Manager on the team. There is a distinct role for Product Marketing that sometimes doesn't manifest in product companies until they've reached a certain stage in their growth. Until then, those key activities and responsibilities will be carried out by people in other positions, who probably already have too much to do.
I was one of those people.
Our company had finally reached that growth stage and now had a full-time PMM who was in charge of tackling the myriad tasks associated with taking our products to market.
What drove this decision
As you might expect, our new PMM became busy as well, dashing any aspirations I had of working side by side with her on a regular basis. We both still had many other priorities competing for our respective time.
But there had been some early achievements. Over the past few months, I was able to transition the Release Communication planning that accompanies each formal product release. Neither of us was ready to put those tasks on auto-pilot just yet and expected to do some additional tweaking. Beyond that, we were eager to tackle a whole host of new product-related activities that we would now be capable of performing. This would require more coordination.
The decision: Regroup with my counterpart in Product Marketing to get our collective and connected plans in order.
I will admit that, up until recently, my priorities and focus around go-to-market had always been more short-term in nature:
- How do we pull together and update all the product collateral for the upcoming product release?
- Who is writing the Release Notes, delivering the webinar, training the Sales Engineers?
- What needs to change on the marketing website, in the knowledge articles, in our sales presentations
- How are we communicating changes, if any, in our pricing or bundled offerings?
- Do we have customers that can help us with promotion via testimonials, reviews, or case studies?
All these questions and more are now being fielded by our PMM but I still care very much about the answers and outcomes and, in many cases, am still on the hook for supplying some of the critical details.
Plan of attack
Weeks had passed with very infrequent contact between us so we had more than a few ducks to get in a row. We had to square away some short-term tasks and also finalize a few of our longer-term projects.
Revisit the Release Communication Plan
We had been executing well on the Communication Plan for the last few releases. It was now a familiar exercise but one that still requires coordination. Given that this was our last big push of the year, we were both hoping to finish strong.
Methodically, we walked through our checklist which included, among other things:
- Creating the material, prepping, and rehearsing for the post-release webinar
- Sending the series of teaser emails to customers to register for the webinar
- Conducting brief user surveys before and after the release
- Crafting a press release for one of the prominent new features
- Refreshing the internal sales collateral to better communicate the enhanced product messaging
- Updating the technical sales demos to reflect the product updates
Prep for upcoming talks with Analysts
In a few of our larger sales opportunities, we were painfully reminded of how important it was to have visibility with prominent industry analysts. In response, the company had launched an initiative to get us back on the industry analysts' collective radar and re-introducing them to our latest and greatest from the product side was a big part of that push.
Building on some introductions and (albeit brief) conversations we had had with analysts at a recent trade show, the PMM had set up some individual briefing calls to re-engage with these industry experts. She and I walked through the schedule and the best way to approach each call to maximize credibility with our larger customers and prospects.
Complete last steps of new product launch
Flickr image source: http://tinyurl.com/qb836wj
One of the best things to happen this year for me was launching a brand new product to the market. It was my first since stepping into the new role and I was eager to see it take off.
The PMM and I had been executing a solid product rollout plan for several weeks now and we were nearing the end of the operation. The final steps were to get the new product listed in a prominent app store, and then begin a vigorous campaign with the Sales team to introduce and upsell the app to existing customers.
We confirmed that after testing the response from our core base, we would ramp up the product marketing efforts and make a much stronger push to the greater market.
The impact
It is a satisfying feeling to get caught up when you feel behind. We both came away from our meetings this week more confident about our plans for the rest of the year. In my opinion, regular email-based discussions and ongoing status updates are often adequate but, for the critical matters, I'll take uninterrupted, face-to-face meetings any day of the week.
Look for more reports from theProductPath around product releases, managing stakeholders, and product feedback here on PM Decisions.
More articles from our blog PM Decisions
Celebrate product wins big and small
It's easy and obvious for everyone to come together and share in the company's larger victories like closing a big deal, but I decided to devote some time to acknowledge, if not revel in some of our minor triumphs too.
The Product Decision: Recognize and applaud the lesser product successes too.
Flickr image source: http://tinyurl.com/ppparbe
It's easy and obvious for everyone to come together and share in the company's larger victories like closing a big deal, but I decided to devote some time to acknowledge, if not revel in some of our minor triumphs too.
Last month, we executed the largest sale ever in the company's history. And while there was no small amount of boisterous high fiving going on over in Sales, it was a great opportunity to bring all the departments together and spend a few moments cheering as a single group.
A big product win too
I was celebrating of course but for a slightly different reason. I was particularly encouraged by this deal because of how it reflected on our current product. It would seem that we had met the customer's needs exactly. After concluding a long sales cycle (not uncommon for an enterprise software company), we signed a contract with the customer without having to promise any changes in the core product or adjustments to the roadmap (quite uncommon for an enterprise software company).
Rarely have I been able to avoid the uncomfortable product roadmap discussions with well-meaning prospects on one side and hovering, commission-obsessed sales reps on the other, trying to move the deal along by finding the right words that would address the urgent needs for "missing" features.
Product Managers dream of building the exact right product for their target customers and when a big one lands, you have to feel good about it.
So this was indeed a victory for Product and also for our dear friends in Product Marketing. Product Managers dream of building the exact right product for their target customers and when a big one lands, you have to feel good about it. But those victories can be short-lived as all eyes inevitably turn toward the next challenge.
What drove this decision
It is hard to say if or when we'll ever top this milestone, but it was another event that happened this past week that made me stop and think about the smaller accomplishments that also deserve recognition.
We had recently rolled out a new product which has been well-received by customers. One, in particular, an early and avid adopter, had recently become frustrated when a change to their own production environment temporarily "broke" our app. They called up and asked us to help remedy the problem because they couldn't go back to the way things were before using our app.
I immediately thought of that great 1-question survey popularized by Sean Ellis that helps Product people test for this exact outcome: if enough users respond by saying that they would be "very disappointed" if they were not able to continue using your product, then you should feel confident that you are the right track.
We had experienced that exact outcome and even if it was only 1 customer, I still call that a victory! And I wanted to play up those wins with the troops too.
The decision: Recognize and applaud the lesser product successes too.
As a senior team member in the company, I have more visibility than most when it comes to departmental activity. I see the accomplishments being made every day and now I wanted to share those positive results with the appropriate parties who were not always directly connected to the action.
Plan of attack
My loose "plan" was simply to keep an eye out for opportunities where I could funnel reactions and reports back to the folks who would otherwise not hear of them. Along the way, I was a little curious to learn that there were not enough regular channels or venues for doing this and that sometimes, I had to get a little creative.
Share glowing feedback from a significant product demo
Early in the week, I delivered a custom product demo for an important, external party who I would position somewhere between future business partner and potential investor. Several times during the demonstration, I received compliments including an amazing, unsolicited comment from one of the women who was "weeping a little," wishing she had had the chance to use our product while working for her previous company.
At the very next Engineering standup meeting, I relayed the flattering remarks with the team. Some rolled their eyes at the glowing hyperbole, but I could tell they appreciated the message.
Appreciate engineering feats
Flickr image source: http://tinyurl.com/olfywby
Later in the week, we reached what I called a golden spike moment, referring to the 19th-century achievement of connecting the two sections of the First Transcontinental Railroad. In our case, two Engineering teams had connected a major new feature with its corresponding new configuration page.
We were now able to demonstrate how to build a new configuration and then immediately use that to launch the end-user tool. Achieving this (long overdue) task meant that we could now address a key pain point for our customers. I celebrated by delivering artisanal pastries to the teams at the sprint planning meeting.
Join in the "New features" huddle
The Product team was very excited to have rolled out two new, high-profile features in the last major release. However, we knew to temper our enthusiasm as it often takes several weeks or even months before customers latch on to and begin utilizing them in any significant way. Such is the pace of B2B software.
But one early indicator of success is when our own internal implementation team picks up the new stuff and starts incorporating into their projects. During this same week, we were pleased to see our folks schedule a huddle to share some early tips and best practices with each other - a true indication that we had delivered something of value.
I invited the Product team to listen in on the discussion and together we basked in the indirect validation as we heard stories about how the new features would ultimately make their jobs easier and deliver better value for our customers.
I celebrated the win with the Product team over a nice lunch (which I ultimately turned it into a working lunch to conduct a customer journey mapping exercise - ha!)
The impact
You don't need always need to celebrate with free food, but I have found that people do like to feel appreciated. Our teams have certainly responded to the positive reinforcement and I will continue to keep an eye out for opportunities to share good tidings.
Look for more reports from theProductPath around product culture, product feedback, and validating products 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.