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
Brainstorm a product solution for customers
After collecting far too many stories about how customers had resorted to stitching together different parts of our product to solve the same problem, I decided to regroup with the extended product team to revisit how we might address the actual needs of our users.
The Product Decision: Go back to the drawing (white-) board to review this prominent customer use case and find a more suitable way to solve this for our users.
Flickr image source: http://tinyurl.com/okhuqz2
After collecting far too many stories about how customers had resorted to stitching together different parts of our product to solve the same problem, I decided to regroup with the extended product team to revisit how we might address the actual needs of our users.
I can measure the age of some of our primary product components in terms of years. This has positive and negative implications. On the plus side, I have a wealth of real-world application to draw upon as generations of users have been recording feedback with us about what is and isn't working (it is not uncommon for us to work with multiple Administrators at the same company due to turnover). All this input gives the team and I a wealth of information to sift through to find patterns of use.
On the other hand, I now also have both a significantly hardened code base that is more difficult to change and a larger user base that would be affected by any serious product revisions.
What drove this decision
I first started seeing the patterns emerge when I was embedded with the Sales Engineering team. Customers were asking for a way to start the same business process from two different points. We had built a tool specifically to accommodate the first case but unfortunately, to address the other starting point, we and ultimately our customers, were forced to reach for an alternative component.
Administrators found that configuring this second approach was harder but what's worse is that the resulting activity provided a completely dissimilar end user experience!
When I spoke with our Professional Services team who often assist new customers with their initial implementation, I confirmed that this was a common scenario and there was indeed pent up demand for a better solution.
The decision: Go back to the drawing (white-) board to review this prominent customer use case and find a more suitable way to solve this for our users.
I didn't feel like we needed to start with a blank page. After all, our customers had all found a way to make our software work and many of them had taken the exact same approach to get there. What was bothering me was that we hadn't given them an obvious solution path and more importantly, the end user experience was disjoint and reflected poorly on the product.
By gathering in one place the sharpest minds from each relevant department in our company, I would have an opportunity to apply some good, creative thinking to the problem. But leading a group discussion like this, especially with multi-disciplinary lineup would require some planning and coordination.
Plan of attack
I had been gathering details around this problem for months, and so I set about reviewing my notes to create some initial hypotheses. I poured through my notebooks, Jira stories, customer interviews, and related research to organize my thoughts.
In the end, I had some solid starting points for the discussion but stopped well short of outlining a final solution for fear of stifling the creative process.
Prep ahead of time to streamline the conversation
I had some presumptions for how I thought (hoped?) the brainstorming conversation would go. The day before, I stayed after work and put some initial thoughts on a big whiteboard. My intent was to use this as a backdrop for the dialogue.
In my experience, I have found that it is much easier to get people talking when they already have something to bounce ideas off of even if the starting material is somewhat inaccurate or incomplete.
Assemble a good quorum
I was genuinely interested in securing multiple points of view, but I also wanted to cover my bases so that the outcome could be vetted by all interested stakeholders. To that end, I invited participants from Engineering, UX, and Product as well as from Sales and Professional Services.
The latter was crucial for validating and clarifying the customers' challenges. The former ultimately helped me discover a product solution that was feasible and usable.
Have open-ended questions ready
Brainstorming often works better when there is some amount of prompting involved. I had already planned to facilitate but in a larger group, it can take actual prodding to make sure everyone's voice is heard. I prepared questions, some technical and others around usefulness, to provide sufficient opportunities to participate.
Even if I had already known the answers to the questions, I would still have incorporated them as collaboration tactics to get the ideas flowing and to promote a healthy discourse.
Stay on topic
Brainstorm sessions are expected to wander a bit which can actually encourage involvement and inspiration. But I had scheduled a short meeting so I also had to make sure I got what I needed from the group to be able to move forward. The trick was to limit the number and scope of conversation topics.
I started with a clear topic outline and stated what I needed the group to help me achieve. A few times I had to gently steer the discussion to get it back on track or to park issues that would have derailed us or sapped valuable minutes.
The impact
My meeting of the minds was ultimately a success. We confirmed several of the core hypotheses and as a result, I was able to proceed with my product planning. I was also pleased to have several new ideas enter the mix as well. In fact, there was one outcome in particular that I did not anticipate and that ultimately proved to simplify the resulting solution.
The approach I described here is a more formal approach to brainstorming, but it worked well given my constraints. With a bit more preparation up front and some lightweight oversight for the actual discussion, I was able to achieve positive results in a relatively short period of time.
Look for more reports from theProductPath around product strategy and product culture here on PM Decisions.
More articles from our blog PM Decisions
Build a quick proof of concept
After realizing that I had failed in my previous attempts to head off a questionable new product idea being advocated by our head of Sales, I decided to fabricate a bare bones working example to advance the conversation.
The Product Decision: Outsource a simple prototype to an overseas development partner to avoid disrupting the in-house Engineering team.
Flickr image source: http://tinyurl.com/o8lbm83
After realizing that I had failed in my previous attempts to head off a questionable new product idea being advocated by our head of Sales, I decided to fabricate a bare bones working example to advance the conversation.
To be honest, I was more than a little intrigued by the new product being proposed, not because I thought it would prevent us from losing deals to our competitors - to my knowledge, we hadn't lost any yet, at least not for this supposed product gap. And it wasn't because the technology was particular fascinating or exclusive - in fact, many of our customers could likely build a lightweight version of this on their own without much trouble.
I'd have to say my curiosity was driven by the opportunity to create something new.
Our company has been building a large software platform for over a decade and it increasingly becomes harder and harder to innovate when you're towing along such a hefty code base.
One of the classic mistakes companies can make is to blindly pursue building a new product just because it is feasible for them to do so.
But I wasn't going to let my own fascinations cloud my judgment. One of the classic mistakes companies make is to blindly pursue building a new product just because it is feasible for them to do so. I know better than that and I didn't want to carelessly lead my team down the wrong product path.
The next step then, was to find a way to better validate the claims coming from our own Sales team but to do so with the minimum amount of effort and investment.
What drove this decision
This is a simple chart I created to help drive more meaningful conversations with our Sales team. I have yet to get them to pin down all of these numbers for a given "missing feature" but in their defense, we don't really collect and track sufficient/suitable data in our sales process to drill down this far. Still, this model does help to frame product investment decisions.
Our Head of Sales was steadfast, still convinced that our product had to have this missing functionality, mostly because our chief competitor was flaunting their own version in front of our prospects. I had tried - and failed - to squash the idea before it gathered any more steam. It was becoming clear to me that I would have to dedicate more cycles to this product proposal even if the end result (i.e. not moving forward) was the outcome.
My chief problem, however, was that our Engineering team was booked solid for the next few sprints and I didn't want to distract them with a side project that was still a long way off from being productized.
I needed a way to make some incremental progress with the new product idea without impacting the team's current development velocity.
The decision: Outsource a simple prototype to an overseas development partner to avoid disrupting the in-house Engineering team.
Giving a new project to an external team can be tricky. My goals were to properly scope the work up front, produce the desired results quickly, and have a clear path forward when the project was complete.
Plan of attack
I was focused on reducing the size of the project to the point where I had what I needed to start validating the product with our end users and prospects. That meant more than just providing good requirements however. I also needed to give the remote team the support it would need to complete the job and deliver the goods.
Define basic requirements and allowable shortcuts
One nice thing about sharing early prototypes such as wireframes or mockups is that your intended audience will often be very forgiving. I have found that when provided with sufficient clarification, users will focus on what's there and not obsess about what's not yet there.
I wanted to make sure that the proof of concept had enough relevant functionality in place to confirm our initial hypotheses. I also wanted to identify places where we could safely skip over steps that would have to be part of the final solution. These include the compulsory but more technically challenging operations like installation and authentication.
I wrote and delivered the requirements to the remote team being careful to emphasize the elements that would have to perform accurately for the end user. I then highlighted the remaining elements that didn't contribute directly to the end user experience where I felt we were safe in taking time-saving shortcuts (i.e.. "just hardcode it for now").
PROVIDE TECHNICAL SUPPORT TO TROUBLESHOOT the remote work
Our remote development team had been working with the company for several years but some new faces were joining this project. To make sure they could ramp up quickly and avoid any first-time stumbling blocks, I recruited a few key internal, technical resources to help launch and support the effort.
As it turns out, the remote team did hit some stumbling blocks in their attempts to use our new API and in resolving those issues, we actually uncovered - and fixed - some problems with our own API deployment process!
Secure the POC artifacts for the next round
When the proof of concept was finished, I had the remote team demo it to a few folks from our Engineering and Product teams. We were all pleased to see the results and I felt confident that we now had a suitable working model to go back with our Sales team and begin engaging customers.
The impact
I had already expressed my doubts to the Sales team about the actual effects of adding a component like this to our product mix - specifically, that it would not significantly advance competitive deals that are in jeopardy. With a working proof of concept in our hands now, it would be easier for us to determine exactly what (would-be) customers were looking for and whether this would affect their buying decision.
I would still have much more work to do in building a truly shippable product if I was wrong and customers latched onto this proof of concept. But I am convinced that I made a good tactical decision at this point and that we would realize a good return on this particular product investment decision.
Look for more reports from theProductPath around product validation, feature prioritization, and managing stakeholders here on PM Decisions.
More articles from our blog PM Decisions
Make Product Decisions Like Cagan
In what many Product Managers might consider an average week, I made three classic product decisions that would make Marty Cagan smile.
The Three Product Decisions: Determine what was most valuable for our customers, what was most usable by our end users, and what was most feasible according to our Engineering team.
Image sources: https://www.flickr.com/photos/68751915@N05/6848823919, https://www.flickr.com/photos/nataliedowne/6446884983, https://www.flickr.com/photos/norue/9625271288
In what many Product Managers might consider an average week, I made three classic product decisions that would make Marty Cagan smile.
After spending more than 10 years in the Product Manager role, I can't actually recall an average week. Perhaps we are attracted to the role for that reason - because it is unpredictable. If it's not changing requirements at one end, then it might be new technology "insights" at the other. The cast of characters we will work with week to week is variable too as new customer prospects enter the picture and compete for attention with existing customers that have their own unending wish lists.
To be successful, Product Managers must be able to navigate these challenges week to week. Good mental frameworks are essential to making sound decisions and to maintaining credibility over time. When you are feeling overwhelmed, however, you may find it helpful to confront the tough product decisions with this deceptively simple approach.
Inspired - How to Create Products Customers Love by Marty Cagan
What drove these decisions
Most Product Managers have run across Marty Cagan’s book Inspired - How to Create Products Customers Love. I consider it a must read for anyone in the general vicinity of Product Management.
Among the many gems in this book, Cagan identifies three fundamentals ways to validate your product decisions: determine what's valuable for your customers, what is usable by your users (not always the same personas as the actual buyer), and what is feasible given the resources you have at your disposal.
These are not mutually exclusive. Whether you're early in your product discovery or tackling a thorny issue for customer 10,001, you need to land on a resolution that best balances these three forces in order to move forward.
Over time, with practice, this starts to become instinctual and woven into your daily PM routine. You may even be surprised, as I was, in reflecting back on an "average" week that there is a very valid reason for why many of your product decisions had turned out so well.
The Three Product Decisions: Determine what was most valuable for our customers, what was most usable by our end users, and what was most feasible according to our Engineering team.
In this particular week, I made and can highlight three, separate decisions for our product and ultimately, for the future success of our company. What makes these particular decisions stand out from the dozens I made is that each was particularly punctuated by one of Cagan's three principles.
Plan of attack
Decision 1 - What’s MOST Valuable
The team had been exploring how we could redesign an existing product feature and was driving that discussion using input we had gathered from rounds of customer testing. As we unwound the different pieces of the story, we revealed the true underlying complexity and ultimately determined that it was too big to tackle all at once.
I decided to break up the larger story into 3 smaller, discrete pieces and sequence the resulting work to deliver incremental improvements over time - a common problem solving approach. But this decision made it much easier for the team to single out which piece would ultimately provide the most value to our customers and, all other dependencies aside, which we would schedule first.
Decision 2 - What’s MOST Usable
In a separate thread, the team was reviewing feedback we received after showing a proposed new design to some of our end users. We had been planning to introduce a completely new design to address some known usability problems with a particularly popular feature.
Few things are more influential for a Product Manager than hearing end users describe how they use, or would use your product to do their job. It was precisely this feedback, straight from our users' mouths, that prompted me to scale back the new design. It turns out that we had been overthinking the problem and could actually deliver a more usable solution with fewer changes (i.e. less work on our end).
Decision 3 - What’s MOST Feasible
Software Engineers like to explore new technology. I know this from having spent the first 10 years of my career as an enterprise software developer. In this current company, I had been having conversations with the Engineering team about how we would tackle a large, scale-related challenge deep in the bowels of the platform (not customer facing). The team had fully researched and had achieved some early success with an alternative technology that seemed applicable for this particular problem.
So, in this very same week, we had come to a point where I needed to make the call on whether to schedule the scale-related work for an upcoming release. And while the Engineering team was convinced the technology would ultimately solve our challenge, we were not jointly confident in our collective ability to proceed safely. Because of this uncertainty around technical feasibility, I swapped out the work from the release, postponing it for a later date after more research and experimentation could be done.
The impact
As I mentioned at the start, these types of decisions are commonplace in a Product Manager's average week: problem decomposition to help reveal customer value, user testing to help reveal usability concerns, and ongoing engineering R&D to help reveal feasibility limitations. Still, it never hurts to return to some of the core product principles to remind us all why we are here. And thank you Marty Cagan for all your contributions, and for inspiring me.
Look for more reports from theProductPath around Product Feasibility, Usability, and Value 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.