Prep teams for upcoming trade show
Knowing that our most important industry trade show was barely a month away, I wanted to do my part to make sure we were adequately prepared and that our products were positioned to show well at the event.
The Product Decision: Kick off early planning for the show to synchronize all the product-related activities across departments.
Flickr image source: http://tinyurl.com/pynmbgf
Knowing that our most important industry trade show was barely a month away, I wanted to do my part to make sure we were adequately prepared and that our products were positioned to show well at the event.
Trade shows can be ideal opportunities for Product teams. If your company registers as a vendor, you can take advantage of your booth space and deploy an engaging team to help introduce new products and announce exciting new features to people cruising through the exhibition hall maze.
You may also gather lightweight customer data from the dozens of rapid conversations your booth team will have with passers-by. If you have already nailed your target market and are promoting the right product messages ahead of time, some may actually seek you out as they wander the aisles.
Even when you don’t have a booth and are just registered as an attendee, you can still take advantage of the fact that for a few days at least, a highly concentrated population of your potential customer base will be under one roof. With enough planning, you could still set up meetings with key prospects, industry analysts and partners. You should also carve out some cycles in your schedule to gather information to update your intel on the competition.
I wouldn’t exactly call us trade show veterans but over the years, we had steadily improved our collective efforts. This year, I wanted to raise the bar even higher, especially for my team.
What drove this decision
This annual industry event precipitated our biggest marketing campaign of the year and we intended to pull out all the stops. We started setting up meeting schedules with customers and prospects weeks in advance and of course, were busy making preparations to lure in new contacts and leads. That meant crisp product demos that hit all the right notes. We needed to highlight the latest improvements to our story in a concise but captivating way to increase our chances of engagement.
Most of our close partners would also be in attendance and the show would provide us with an opportunity to reconnect with them as well, exchanging updates and looking for new integration or implementation options to serve our joint customers.
This was going to take some coordination - none of it was going to just happen magically.
The decision: Kick off early planning for the show to synchronize all the product-related activities across departments.
We needed to highlight the latest improvements to our story in a concise but captivating way to increase our chances of engagement.
I don’t think it’s wise to pin all your product/sales hopes on a single event but I have seen first hand how a large industry event like this can become a natural rallying point for the Product, Marketing, and Sales teams.
I had already coordinated our next major product release to line up with the event dates so that we would have exciting new announcements to share at the show. That was a good start.
To make sure we would get the most out of the show, I would need to circle back with other departments to work on making all the other pieces fall into place.
Plan of attack
With good preparation, we would likely have hundreds of opportunities to tell and sell our story to a mostly captive audience. I wanted to support our company's collective efforts and put our products directly in the spotlight. That meant having persuasive product demos, queuing up notable product announcements, promoting influential partnerships, and more.
I also had to make sure my own team would be taking full advantage of all the available resources at the show.
Review product demos with the Sales Team
I started by spending some time with our Sales Engineering team to review the product features that I thought should be highlighted to create compelling demos for the traffic we would see in both the booth and in our private meeting rooms.
We rely on Sales Engineers to help execute the technical part of the B2B sales process. Together with the Sales Reps, they will tailor and deliver product demonstrations based on a joint understanding of the customer's needs. At a busy trade show we don't often have the time to fully qualify leads and so we have to tweak our methods.
In recognizing that most attendees would not be able to spend more than a few minutes with us, we optimized the familiar customer story to have even more impact in a shortened discussion.
Confirm launch plans for a new product
Flickr image source: http://tinyurl.com/nghc5jl
Our big theme for this year's show was around the launch of our new mobile application. My partner over in Product Marketing had started orchestrating a full communication plan which would culminate in a product unveiling at the upcoming event. Aside from being able to show off the product itself (see Demos above), I wanted to make sure all our messaging was on target.
We had also been seeking out opportunities to further promote the new product outside of our own booth. For example, we applied for and were awarded a special "innovator" designation in the vendor listings. We also secured a coveted time slot to present at one of the show's more prominent venues where I would have much more time and resources to advertise our newest offering.
Finalize partnership integration announcements
Through discussions with a few of our strategic partners, we had determined that the trade show would also be a great time to create some joint buzz. One integration partner, for example, was going to use the show to significantly step up their own presence and our company had a part to play in that upcoming marketing blitz.
With another partner, we focused on a more tactical story. Rather than each of us independently promoting our own products, we agreed to highlight product integrations and the success our customers had realized by using our respective public APIs. Of course, it always helps to have these customers come forward and attest to our claims.
Synchronize agendas with the Product team
And finally, I sat down with my own team to review our strategy for consuming as much information as possible during the show. We walked through the complete list of formal sessions, scheduled workshops, and other informal gatherings to build agendas that would provide maximum coverage. It was tempting to completely fill up everyone's calendar but we also wanted to be able to accommodate spontaneous and unplanned events as well.
The impact
At the time of this writing, the trade show is still more than three weeks away. There will likely be many more details to work through before we all hop on airplanes and head out. I feel good about our preparation to date and will continue to push all the teams to band together to deliver a positive outcome for our company.
Look for more reports from theProductPath around managing product teams and getting out of the building here on PM Decisions.
More articles from our blog PM Decisions
Initiate a few modest R&D projects
After getting our major roadmap items underway and finding our rhythm with smaller bugs and enhancement requests, I decided it was time to launch a series of background research tasks.
The Product Decision: Recruit uniquely qualified resources to kick off independent, well-scoped initiatives with a high potential to excite both customers and stakeholders.
Flickr image source: http://tinyurl.com/p4s27js
After getting our major roadmap items underway and finding our rhythm with smaller bugs and enhancement requests, I decided it was time to launch a series of background research tasks.
I don’t want to give the impression that we have tons of spare bandwidth. We are struggling with the same resource constraints that plague most Product teams but I believe there is value in prudent technical experimentation. In my experience, even the most ambitious Product Roadmaps are primarily designed to keep everyone going down the same path and they don’t afford much room for concurrent product exploration - and I’m not talking about unexpected wrong turns!
Sometimes you need to launch a few parallel pursuits to introduce new ideas and shake things up.
What drove this decision
I continue to be impressed with our entire technical team and am convinced that there is even more potential there that we can tap into through targeted endeavors. In this case, the team had been making favorable progress on several, in-motion product initiatives and that prompted me to think a little further out than I had been.
Several months back, we had embarked on a plan to upgrade some of the underlying technology in our core platform, partly on the promise that it would deliver advanced functionality above and beyond the legacy components it was replacing. We were now closing in on a major delivery milestone and had a sound plan for the upcoming transition. That inspired confidence and afforded me with some breathing room to further explore the features of this new technology.
Sometimes you need to launch a few parallel pursuits to introduce new ideas and shake things up.
Separately, in another work stream, we had been investing a great deal of resources into building a new data repository to capture information related to the user activity in every automated business process. The initial payoff would be the launch of a new mobile application which gives users unprecedented visibility into their own workflows.
The mobile app was now being rolled out to customers but that initial investment was always intended to yield more for us and for our users. This seemed like a good time to start work on the next phase of that product initiative.
The decision: Recruit uniquely qualified resources to kick off independent, well-scoped initiatives with a high potential to excite both customers and stakeholders.
R&D efforts are not always guaranteed to deliver positive or even actionable results. Still, I didn’t want my first ventures to fall flat as I intended to follow up with additional waves of experimentation. Ideally, the R&D projects would help to determine which ideas were feasibility and for those, what we should expect in terms of level-of-effort to implement, deliver and support them. This would help me assess how and when to fold them into the Product Roadmap.
I was also planning to share the results with the Management Team and our Board in order to show what we might be capable of delivering at the far end of the Roadmap. A secondary goal for me then was to demonstrate early success and improve the chances of funding future R&D work.
Plan of attack
These initial projects were trial balloons for me and the Product team. If we succeeded in producing positive results, we were likely to be encouraged to continue exploring and experimenting. To increase our chances of success, I took care to limit the scope of each effort, to pick the right team resources, and to schedule shorter term deliverables.
Disclaimer: As R&D projects can be sensitive and can often impact a business' competitive advantage, I have chosen to sanitize and share just 2 of the projects here.
Project A explored the viability of an inverted search feature that enables an end user to determine if a given document matches one or more search terms. Our customers have shared use cases where they need to know if a modified document still contains one or more paragraphs, terms, etc. An inverted search could discern whether a given contract contained one more standard clauses for example.
Project B looked to expand our company’s use of analytics to report on and ultimately improve document workflows. Customers were already investing heavily into our platform’s workflow features to automate their business processes and I wanted to be able to give them much more data to evaluate the people, process, and documents involved in those workflows.
Scope each effort
In my opinion, the most important factor for success was in how we defined the projects. Too broad and we might never see any results. Too small and they may be de-prioritized or even dismissed.
For the first project, I needed to show the general applicability of the inverted search and the relative effort to configure the function. We didn’t need to tackle complicated documents or complex search terms but we did need to stay relevant to our customers’ use cases. The goal for this project was to prove the feasibility of the technology - usability would be addressed in a separate effort.
The other project was quite different. Here I was looking to identify the overlap of actual customer inquiries and available analytic data. The goal of this project was to find as many good matches as possible between what our customer research had surfaced around visibility into workflow processes and the rich analytics we could be generating in the future.
Enlist Internal and External resources
Flickr image source: http://tinyurl.com/p2b248t
To kick off Project A, I cornered one of our Software Architects and bribed him with pastries - a low-cost recruiting tool! He is the resource who was primarily responsible for introducing the new technology to the Tech team and who had been overseeing its implementation during the past few months. I sat down with him and painted the picture of how we could use the advanced features of this technology to address real customer problems that were going unsolved. He understood the benefits and like me, recognized the large payoff of a relatively minor product investment. I had no trouble convincing him of the value of a proof-of-concept and promised to carve out time for him to explore this during the upcoming sprints.
For Project B, I went outside the company to find subject matter expertise. I had been introduced to a woman who specializes in all things data, metrics, analytics, and visualization. I had seen examples of her previous work where, given very little in terms of schemas or actual data, she produced some amazing and insightful dashboards. This was exactly the kind of impact I was looking to make with our own embryonic data store. After explaining what little I had to start with but where I was hoping to go, she presented a reasonable proposal that fit within my time and budget constraints. There were very few dependencies on our own internal resources and indeed most of the Tech team had little knowledge of the project. I did pull in our heads of Engineering and UX to help keep me honest and on track.
Timing the project deliverables
As part of the scoping effort, I created schedules for each project that would produce results in a meaningful timeframe. Our next major product release had already been scheduled to coincide with an upcoming industry event. We already had plans to show off the latest product improvements at the trade show but if some of these R&D projects panned out, we would have even more to entice customers and partners.
The impact
Based on this preparation, I was able to get my R&D projects approved, funded and launched successfully. The early evidence is mostly positive and we seem to be on track to deliver on the goals I set early on. Now I'm engaged in some early internal promotion around a few of the projects and have even started to leak some preliminary results to our CEO and our head of Sales to validate the intended ROI. I'll share more progress updates in the weeks ahead.
Look for more reports from theProductPath around product strategy, roadmap planning, and product investments here on PM Decisions.
More articles from our blog PM Decisions
Guide and advise fellow Product Managers
After many rounds of discouraging conversations with less experienced and struggling Product Managers both inside and outside my own company, I decided to assemble and share some helpful resources for advancing one's own PM career.
The Product Decision: Create simple orientation assignments for Product Managers who have a genuine appetite for advancing their careers.
Flickr image source: http://tinyurl.com/plxquqy
After many rounds of discouraging conversations with less experienced and struggling Product Managers both inside and outside my own company, I decided to assemble and share some helpful resources for advancing one's own PM career.
I believe that we are still in the early development stages of the Software Product Manager (SPM) role and also, that there is a general lack of clarity around this particular breed of Product Manager. That would certainly explain the flood of books, articles and similar resources all aimed at helping PMs understand and navigate this career path. But along with those are an even greater number of online conversations that seem to add to the confusion by attempting to explain it.
Here are a few of the top links returned when searching for "What is a Product Manager":
- What, exactly, is a Product Manager?
- Product Manager 101: What Does A Product Manager Actually Do?
- A Product Manager's Job
- Product Managers: Who are these 'mini-CEOs' and what do they do?
For someone who has recently landed their very first Product gig or is just looking to transition into becoming a Product Manager, this visible and honest industry conversation is simply an indicator of how confusing it can be to get started. And while there are some terrific resources being developed, most new PMs don't even know where to begin.
What drove this decision
Closer to home, I knew of three individuals at different stages in their own PM careers who were each struggling with the similar problem.
Arthur was already pursuing a UX calling and was a semester away from earning an advanced degree in that area but had spent enough time around Product people to become intrigued with the role and was now curious about whether he could do both.
Brandon had been tapped by his current company 2 years ago to take on a Product Management role after proving himself as a reliable project manager and was now convinced that he wanted to find his next Product opportunity to continue down this path.
Carl had been a Product Manager for several years but had received no formal training and while he had mastered the more tactical activities of getting customer requirements through Engineering to deliver features to customers, he didn't know where to start to improve beyond that.
I found myself in impromptu mentoring conversations with all three in the span of a single week. I took that as a good sign to revisit my own collection of PM material and pull together suitable resources for at least these three practitioners.
The decision: Create simple orientation assignments for Product Managers who have a genuine appetite for advancing their careers.
The challenge was not finding relevant material but rather curating the collection to zero in on the items that would have the biggest impact. I was looking for artifacts that would be easy to consume, that would provide good direction in the short term, and that might inspire them to explore topics even further on their own.
Plan of attack
These three colleagues were in different stages of their careers but I knew that all of them would benefit from some strong, foundational material. There is a growing body of informational resources for the SPM but I didn't have a place to point them to get started.
Required Reading (AND LISTENING)
Inspired: How to Create Products Customers Love by Marty Cagan
The first question I always ask Product Managers who are just getting started is whether they've found and read Marty Cagan's book, Inspired - How to Create Products Customer Love. I have received nothing but rave reviews from every person to whom I've recommended this book.
I consider it required reading -- and re-reading. It is easy to consume and is filled with great advice for PMs at all stages. But perhaps the greatest benefit for an early-stage Product Manager is that Cagan clearly outlines the role itself and distinguishes it from the related but often overlapping functions of Project Manager, Product Marketer and UX Designer.
And If you need a break from reading, I can't recommend enough the amazing podcast, This is Product Management, created and hosted by Mike Fishbein. Each episode provides a fresh and unique perspective on this incredible role. Mike recruits inspiring guests who generously share their experiences working in and around the Product function.
Your New PM Job
Gopal Shenoy provides a Getting Started guide for PMs
I then turned our attention to what Product Managers should be thinking about in their early days on the job. Some years back, I came across this wonderful article written by Gopal Shenoy called Software product manager’s first 30 days at a new job …. In it, he lays out a great guide for what good PMs do (or should be doing) in their first few weeks. The list is extensive and a little intimidating - perfect for setting a new PM's expectations.
I encouraged Arthur and Brandon to digest Shenoy's 30-day list and create a distilled version for their own use. And if they made it through that, I further suggested that they read his companion article on what to do in the next 45-90 days.
Brandon is actively interviewing but had not yet found some of the great resources that the PM community has contributed for job hunters. I encouraged him to take a look at one particularly interesting app at http://www.thepminterview.com. The author leverages material from Cracking the PM Interview and Decode and Conquer to create an online, interactive exercise where you can practice your answers to sample interview questions.
Formal Training Programs and Peer Groups
I pointed Carl, who was already embedded on a Product team, to look into cursory workshops and/or full, multi-week courses created specifically for Product Managers. There has been an increase in the number of online or self-guided options from companies like Udemy, but I encouraged Carl to look at local options such as General Assembly's 10-week course or the Pragmatic Marketing program. I explained to him that he would enjoy the added benefit of meeting and networking with peers in his own community.
And speaking of networking, I am a big fan of getting plugged into monthly meet-ups and similar informal, after-work forums related to your career choice. Every month, more and more opportunities spring up for Product Managers to meet and share ideas. I told Arthur, Brandon, and Carl to sign up for an upcoming event in our city and even offered to accompany them.
On the Job Training
Fall in love with a product framework
I prefer to give tactical advice when I can. So I followed up on my previous recommendations (read this book, take this class, join this meet-up, etc.) with a single proposal that I would expect each of them to incorporate differently on their own product paths: fall in love with a product framework.
Over the years, the greater Product community has created and shared many formal templates, authoritative checklists, proven models and reusable processes. A few of these attempt to address the entire product lifecycle but I believe that would be exhausting for an up-and-coming PM to consume, much less apply in practice. Instead, I advocate that new Product Managers zero in on a more discrete area, by starting with what interests them the most.
I used this approach when I was first getting my bearings. I was overwhelmed by all the material and product experts I encountered and was struggling to find any method that I could confidently apply. I eventually discovered Marty Cagan's Opportunity Assessment and used this as a foundation for my building my own method.
And I wouldn't discount the searching process itself. You will inevitably stumble onto new ideas just by sifting through the still disperse product knowledge base to find frameworks that interest you.
Volunteer to do a PM's Job
And what do you do with this new framework you've recently embraced?
I was once told that the best way to get into Product Management is to start doing it. This guru urged would-be PMs to hunt down the closest Product team (or whomever is performing that function) and offer to assist. As someone running a Product team, I genuinely like that approach. But I would argue that showing up empty handed is not as attractive as arriving with expertise around some useful tool that the Product team can use to improve discovery, planning, or execution.
The impact
Ultimately, it is up to Arthur, Brandon, and Carl to move forward at their own pace. I'd like to think my advice is helping them to navigate but I feel like we're still far away from having any kind of proven curriculum. Despite that, I'm seeing more and more people gravitate to this kind of role - and I'm encouraging it. The Product community is fortunate to have professionals from so many disciplines join our ranks, making us a much stronger collective.
Look for more reports from theProductPath around Product teams, PM credibility, and the PM role here on PM Decisions.
More articles from our blog PM Decisions
Fire up the Sales team
After being invited to participate in our mid-year, internal Sales team rally, I decided to deliver a rousing product presentation to get the troops pumped up.
The Product Decision: Weave together a powerful before/after story that relates the numerous product enhancements as well as our impressive rate of innovation to stir the team and inspire them to carry that message to our customers.
Image source: https://www.flickr.com/photos/spacelion/3008520385
After being invited to participate in our mid-year, internal Sales team rally, I decided to deliver a rousing product presentation to get the troops pumped up.
Over the course of my career, I have spent months embedded with various Sales teams and I would recommend it for any aspiring Product Manager looking to better understand their stakeholders. Some of their customs, however, may still be a bit peculiar, at least to me. In particular, there is this practice of routinely gathering the entire Sales team for an entire day or two, typically somewhere away from the office with the intent of re-energizing everyone.
I know that the Sales team, like most other teams, have their own set of priorities and that they don't often stay as connected to the products as I would prefer. So I find it valuable to take advantage of occasions like this to better "align" myself and our products with the Sales team.
What drove this decision
We had recently hired some new folks into the Sales ranks over the past few months and the entire team had been focused on rolling out an updated sales process with our revamped Marketing team. This meant less bandwidth for absorbing the last few rounds of product updates.
Everyone in the company is invited to attend our monthly Release Previews of course but Sales attendance, in particular had been somewhat spotty for awhile.
Now, with this mostly captive audience, I had a chance to focus everyone's attention on our Products and to remind the team how much progress we have made in the last six months.
The decision: Weave together a powerful before/after story that relates the numerous product enhancements as well as our impressive rate of innovation to stir the team and inspire them to carry that message to our customers.
I can't blame our Sales reps for settling into a comfortable routine and sticking with a story that works for them. Asking them to change up their narrative every time we release new software is a little unrealistic. But I knew that the product improvements we had made over the past six months had been significant and would have a big positive impact on the way we all were engaging with our customers.
Our company had indeed devoted a great deal of time to understanding our customers' pain and I knew we could speak to that confidently. But I had sat in on enough product demos to know that there were plenty of rough spots - areas of the product that didn't show particularly well. Much of the Product effort in the first half of the year went to address these specific issues and our story needed to be refreshed to incorporate every one of those Product improvements.
Plan of attack
They gave me 60 minutes to dazzle the troops.
They gave me 60 minutes to dazzle the troops. Even the best slides would not likely keep their collective attention for that long so I supplemented a PowerPoint presentation with live product demos and tantalizing prototypes to help keep them captivated.
The goal for me was to have everyone walk away with renewed pride in our company's product and more importantly, for each of them to feel even more confident that we were truly the best option for solving our customers' problems.
Create a backdrop for the main narrative
The first step was to set up a familiar context around which I could piece together the different elements of the story. As a framework for my slides, I decided to use a 1-page diagram I had created months earlier as a sales aid to help orient our prospects and drive productive sales discussions. I began by highlighting a number of improvements I had made in this iteration of the diagram to help me grab the team's attention at the very start.
My (abbreviated) presentation flow for the Sales team tells a before/after story using the familiar customer process as the backdrop
Show old screenshots highlighting the known bad spots
The next step was easy. I found old screenshots from the recent past and positioned them on top of the diagram. This had the intended effect of reminding everyone how hard it once was to brag about our solution. During the presentation, I intentionally exaggerated the struggles associated with this familiar but outdated description of our product - but concluded that this awesome team was still able to sell that version. The good news is that it wouldn't get any worse!
Replace with new screenshots
Then, one by one, I swapped in the new hotness. Gradually, I unfolded our updated story to the group showing how all our pain points had been (or would soon be) addressed. Even better, the Product team had introduced entirely new features that helped to strengthen our overall story. The resulting picture not only improved on the known problems but gave the Sales team even more talking points and would help them address customer issues that we might have dodged in the past.
Tease with early prototypes
But wait - there's more! Stacking up all the existing enhancements on a single slide was certainly effective but to really energize the crowd, I then switched gears and started demoing some of the new stuff that was just around the corner.
Using live code that was still working its way through QA along with fancy, clickable prototypes created by our UX team, I began to weave an even stronger narrative for our Sales team to use immediately with their prospects and customers.
The impact
My talk had the intended effect and I was certainly encouraged by all the positive feedback from the team. I do realize that the real payoff for the company will only come when they carry this updated story to the front lines.
I remember days in recent past where Sales Engineers would brush past certain areas of the product or skip them entirely hoping that the prospect wouldn't notice. I also remember the collective cringe when a savvy customer would ask to explore the next level of detail behind a particularly well-manicured product demonstration.
With this presentation, I made it clear that we would no longer have to avoid those areas of our product. Instead, I urged our team to intentionally stop and even linger at certain points in the demo to prompt more productive conversations. I wanted our customers to ask those tough questions and engage further with us. We had even more reasons to be proud of our company's products and what's more, could now point to an impressive rate of product improvement over the past six months.
Look for more reports from theProductPath around product review, product culture, and socializing product roadmaps here on PM Decisions.
More articles from our blog PM Decisions
Triage an almost bungled feature upgrade
In recognizing that our pre-deployment testing had raised unexpected alarms with some customers and our own Support staff, I decided to straighten out the mess by creating a better feature migration path.
The Product Decision: Instead of forcing a more immediate upgrade on our users, I would stretch out the feature deprecation period and give customers more time and more autonomy to make the transition.
Flickr image source: http://tinyurl.com/pp7daju
In recognizing that our pre-deployment testing had raised unexpected alarms with some customers and our own Support staff, I decided to straighten out the mess by creating a better feature migration path.
We were winding down the days to our next major product release and I thought the planning had been going well. There are always a number of moving parts in a big deployment and it takes no small bit of coordination across teams to pull off a trouble-free rollout.
One of the big announcements this time around was how we had overhauled one of our more prominent features to make it easier to use. And while we had usage data that showed it wasn't exactly mission critical for our existing customers, we still wanted to ensure a smooth migration.
What drove this decision
The upgrade approach we had planned was simply swapping in the new feature in the place of the old one. Any account that was actively using the old feature would continue to work for the 30 days following the release but after that time, all accounts would be have been automatically switched over.
This seemed straightforward enough and indeed, our internal testing and QA efforts proved that this was a clean transition. Where we went wrong however, was not effectively communicating the plan, especially to our internal stakeholders.
The most obvious blunder was in the Release Notes (I wrote) that we circulate internally, weeks before the go-live date. I had made a copy/paste error using some outdated text and reported the exact opposite intent around this migration! As you might imagine, the Customer Success team freaked out when the old feature "suddenly just disappeared".
All fingers were rightfully pointing back to me and my Product Team. What I thought had been weeks of good planning and internal discussion were negated by what was now a small crisis. I needed a good plan to set things straight.
The decision: Instead of forcing a more immediate upgrade on our users, I would stretch out the feature deprecation period and give customers more time and more autonomy to make the transition.
It is worth clarifying that nothing was indeed broken in any customer account and nothing would break as a result of pushing the new feature in the upcoming release. Actually, I could have tried to smooth over the current unrest and push forward as we had originally planned. After all, no actual customer had experienced any problems in their accounts.
But in this case I chose a more cautious path. Even though it would be more work for our tech teams - actually, it would be re-work since we had already removed the old feature and now had to quickly retest the reverted code - I knew the extra effort to create an extended upgrade period would cost us a lot less than having to soothe any confused or disgruntled customers.
Plan of attack
Patience is a virtue - especially in times of crisis. When the voices are beginning to elevate, when email threads are growing exponentially in a matter of hours, and when emergency meetings are being scheduled first thing in the morning, it helps to be able to keep a calm head.
I would have to calibrate our response based on the actual size of the problem.
One of the things I wanted to make sure was that, in attempting to address the problem, we didn't make things any worse than they were already perceived to be. The key to that, in my opinion, was to properly scope the effort. In short, I would need to be able to calibrate our response based on the actual size of the problem.
Understand the full impact of the change
When we did assemble the interested parties in a meeting room and reviewed the situation, one of the first questions I asked was whether we knew the number of customers/accounts that would be affected by the deprecated feature. My own Product team had gathered some numbers weeks earlier but I wanted to know if we had been off in our estimates.
Because there wasn't enough certainty, I had the Engineers run a new set of exhaustive queries to get our hands around the total affected population. Early totals were supplemented by more thorough search results but all reports showed that the impact was far less significant than the recent hype would have suggested.
Flickr image source: http://tinyurl.com/ol3x3jr
Call attention to the deprecated feature
With the Engineering team's help, I committed to reinstating the deprecated feature into the product to help affected customers with their inevitable migration. But in doing so, I insisted that we incorporate some blatant visual cues for the end user so they understood that some action was required.
With minimal work, we were able to introduce a glaring design element intended to draw attention to the deprecated feature. This new call to action would be reinforced with other messaging inside the product and externally as well.
Broadcast (better) to internal and external users
The steps required for a customer to move to the new, improved feature were straightforward and would likely only take a few minutes to complete. However, I have learned the hard way about underestimating users and so, to err on the side of caution, I committed to providing multiple migration artifacts.
I had the Product team scramble to develop new collateral including a 1-page cheat sheet and a short instructional video to help guide customers on the migration process. In both, we explained how the deprecated feature would be disappearing in the subsequent release to be replaced by the improved option available now and we included a recommended course of action to avoid any problems in their account.
The impact
In the post-mortem discussion, all the teams agreed that the new feature is a much better option for our end users - we had just stumbled a bit in our plan to roll it out to our customers. It was a good lesson for me and one that I'm happy to have tackled before the official release where it could really have escalated.
Look for more reports from theProductPath around product releases, product culture, and PM credibility here on PM Decisions.
More articles from our blog PM Decisions
Complete an Opportunity Assessment for proposed new product
After disappointing results from my previous attempts to stall the momentum building around this "must-have" component, I decided it was time to break out the heavy artillery.
The Product Decision: Use Cagan's Opportunity Assessment to approach this product decision with more rigor and less bias.
Flickr image source: http://tinyurl.com/q23ggld
After disappointing results from my previous attempts to stall the momentum building around this "must-have" component, I decided it was time to break out the heavy artillery.
If you had read any of the articles leading up to this post, you might conclude that I have been fighting a losing battle. Indeed, I have been chronicling the story of my struggle with this new product idea over the past few months:
- Head off a new product idea
- Clarify win-loss speculation with post-mortem interviews
- Build a quick proof-of-concept
Each of those product decisions was driven by healthy skepticism around my company's impulsive and in my opinion, short-sighted product recommendation to build an MS Office plug-In. For the record, I'm not against this product idea at all. The campaign I'm engaged in here has more to do with making good, long-term product investment decisions.
What drove this decision
New product decisions should not be driven by fear, such as the purported threat of some competitor's offering. Likewise, they should not be pursued just because the solution appears to be simple to build or is otherwise easily accessible. There are so many more factors that should be considered. And they should be considered together, holistically.
What I needed was a way to communicate the whole picture to my stakeholders. I wanted to engage in an open discussion around all the decision criteria. And I wanted to come into this conversation with the main talking points already distilled from a more thorough study and backed up where possible, by actual data from relevant research.
The decision: Use Cagan's Opportunity Assessment to approach this product decision with more rigor and less bias.
Marty Cagan's Opportunity Assessment is described in his book Inspired - How to create products customers love - a must read for Product Managers.
This product decision really had 2 parts. First, I knew that I wanted to use Marty Cagan's Opportunity Assessment, which is an excellent and straightforward framework for evaluating new product opportunities. I think it is one of the best tools a Product Manager can have in their "belt". I deploy it whenever I encounter exciting new ideas - my own or another's. The Opportunity Assessment helps you exert solid due diligence before a good sounding proposal gets too far along.
Second, I wanted to use the Multi-Tool, a PowerPoint-based tool created by the team at theProductPath for this exact scenario. The Opportunity Assessment Multi-Tool puts Cagan's framework into an easy-to-use PowerPoint structure where the user can capture, then distill, and finally present the Assessment all using the same tool.
Plan of attack
In this particular instance, Cagan's framework lays out the "plan". I stepped through each of the questions of the Opportunity Assessment capturing my answers as best I could. Using the Multi-Tool, I was able to focus on each question in isolation, using the "scratch area" on each slide to record all my rough notes.
When I felt I had sufficient material for a given topic, I distilled a shorter version of the notes in the "summary area" on the left side of the slide (the Multi-Tool shows these boxes in presentation mode while hiding the draft notes).
Below, I have included copies of my rough notes for my company's proposed Office plug-In product. At the end of the article, you will find the distilled version of the notes that I used for the stakeholder discussion.
1 - Value Proposition
I started the Opportunity Assessment by looking at the problem we are trying to solve - not the solution itself. Note that it can often be difficult to focus only on the pain and not talk about the way you or your customers would like to solve it. But here - and this is important - we are trying to assess the opportunity itself, so we can ultimately decide if it is worth solving.
In my case, I had spoken to enough customers and prospects to know that using a cloud-based content repository presented challenges to teams that traditionally work with desktop authoring tools like MS Word.
2 - Target Market
The next step in the Assessment is to clarify exactly who is struggling with the problem(s) identified in question 1. When you have answered these first two questions, you have the foundation of a solid Problem Hypothesis: we believe that [the target user] has problems with [specific task(s)].
I had been able to zero in on the Legal teams as the target users in our customers' organizations who were most struggling with accessing their cloud content from their desktop tools.
3 - Market Size
When you are confident that you know who has what problem, your next task is to determine just how many of these users exist out there. This will give you a sense of your potential market size and should be a good early indicator of whether you're chasing a real opportunity or not.
As you might guess, some of the information in my particular Assessment is sensitive and I have further sanitized it for this article. As compensation, I have included an image of the draft version of the slide where you can see some of the assistance the Multi-Tool provides in the form of notes and pull-out tabs.
4 - Business Metrics / Revenue Strategy
The next topic forces you to think about how you will measure your success if you decide to proceed with the opportunity. I have found that too often, we push forward with new product development and even bring new products to market before we get agreement on exactly how that offering will help the business! That is exactly how we got into the situation I inherited where my company's product portfolio was bloated and unmanageable.
For this assessment, I simply created some placeholders for the ensuing conversation with my stakeholders. I wanted them to be thinking about the revenue impact on our business for sure but also how our customers, our partners, and even industry analysts would ultimately measure our extended product portfolio offering against our competitors.
5 - Competitive Landscape
Now we come to the competitors, or more accurately, the competitive landscape. Because the truth is, you don't always lose deals to another vendor. Sometimes, it is inaction or the prospect's failure to make a decision. Other times, the customer just decides to live with the pain or finds some acceptable workaround.
In our case, I knew what customers had been doing to get by and we had a pretty good idea of what our primary competitor was offering. All the signs would seem to be pointing us toward building our own solution that was more attractive than both the existing alternatives.
6 - Our Differentiator
At this point in the Assessment, it is time to look within. In short, you need to determine, as honestly as you can, why you feel that your company is uniquely positioned to address this opportunity. Put simply, this question is, essentially "why you?"
I saw the customer's problem as a content-related one, and that was certainly within our wheelhouse. Compared to the broad range of functionality we already provide both in the browser and in other desktop applications, I felt that we would be confident in delivering a compelling solution here as well.
7 - Market Window
If the previous question was, "why us?", then this next one could be summed up as, "why now?" Even if all the previous answers had trended more positive than negative, you can still get hung up here.
For example, perhaps the overall market of your prospective users is known to be shrinking. Or perhaps the technology you need to build the product is still immature, giving you good reason to pause. Or maybe it is as simple as postponing this opportunity until after you complete other in-flight projects.
I think my company actually does have some urgency and that if we were indeed going to head up market, then we would need functionality like this to stay competitive. Even though I was still unconvinced that the entire opportunity was worth pursuing, I couldn't deny that the timing was right for us.
8 - Go To Market Strategy
All the white boarding and prototyping and story writing and development and QA and deployment won't amount to a hill of beans if you don't execute on your go to market plan. Think carefully about this topic as you consider how you will get your new product in front of your customers. Do you already have the channels in place or will you be exploring some unfamiliar territory?
This is another area where I have chosen to over-sanitize the material from my own Assessment. I would apologize but I'm sure you can appreciate the sensitivity of this information.
9 - Solution Requirements
If you've made it this far in your Assessment, congratulations - you're in the home stretch. This is where you sit with your top technical folks and have them spell out all the dependencies and unknowns that will affect your development plans. In my experience, this is often a sobering discussion. It's not that Engineers like to rain on parades, they are just blunt and frank by nature - but you need this information to help guide your decision making.
In our case, the list of requirements was quite long, especially considering that all the stakeholders had been assuming this would be an easy win. If I needed more ammunition to build the "no-go" case, then I could count on this laundry list to aid me.
The impact
Cagan's Opportunity Assessment actually has 10 questions. The first 9 essentially prepare you for the last 1: the go/no-go decision. Many times, when using the Assessment, I can stop well before I reach the end when I can see that the target market is not big enough or when the timing is wrong, or when I don't have an obvious go to market strategy. You might think that those are frustrating outcomes but actually, I am always pleased that I arrive at that conclusion before I waste a lot of energy chasing a bad opportunity.
I have yet to share the entire Opportunity Assessment with all my stakeholders but they know it's coming. I'm looking forward to reviewing the information with them and although I'm fairly certain where we will end up, I am genuinely open to the group's collective reasoning.
I mentioned earlier that the Multi-Tool is quite handy when you need to share your Assessment results with others. To demonstrate this, I have included the final Opportunity Assessment here, in presentation mode. Click through the slides to see how the Multi-Tool can also be used to create a beautiful presentation without any additional work. Just digest the best points from each question into the boxes on the left and start the slide show - that's it!
Look for more reports from theProductPath around opportunity assessments, product strategy, and managing stakeholders 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
Write the Release Notes
After realizing my goto resource would be on vacation during the next big deployment, I decided to step in and take the lead on producing the key product documentation.
The Product Decision: Roll up my sleeves, dust off the technical writing skills and crank out the next iteration of our product release notes.
Flickr image source: http://tinyurl.com/ozc9zcy
After realizing my goto resource would be on vacation during the next big deployment, I decided to step in and take the lead on producing the key product documentation.
Our company publishes Release Notes for every major product upgrade. We create this formal documentation for existing customers mostly, as we look to highlight improvements and bug fixes to our software products and any changes in how we deploy, license, or support those products.
I have regularly contributed to this document but have never owned the task of generating and assembling the Release Notes for our product deployments. With each major product release, I have also looked for opportunities to incrementally improve the structure and details of this important piece of product collateral.
What drove this decision
Flickr image source: http://tinyurl.com/njjshos
One of my Product Managers had scheduled some time off of work for a much-needed (but poorly timed:-) family vacation. Up until this time, the Product Team had leaned on him to lead the effort of producing the Release Notes. And he had always come through.
Each time of course, it had been a team effort as each Product Manager was ultimately responsible for capturing and communicating their team's respective work. But "Vacation Guy" had been the one to pull it all together and ultimately deliver it to the eager masses.
His absence would put us in a tough spot - but it also presented a good opportunity for me to pitch in.
The decision: Roll up my sleeves, dust off the technical writing skills and crank out the next iteration of our product release notes.
I was confident about writing the document itself and fully aware of the entire scope of the upcoming release. But beyond the heads-down task of cranking out the words and pictures, I wanted to use this occasion to advance the state of the product communication we use with our stakeholders.
Our new Product Marketing Manager has been pushing my product team to better connect the dots around product/feature positioning.
On a related note, the company had recently hired our first, full-time Product Marketing Manager (a great move) who among other things, is helping us with the many tasks associated with a product release. For example, she has taken over the Release Communication Plan that is used to orchestrate most of the customer-facing tasks like email notifications, blog posts and related content marketing activities, and promoting the post-release webinars. And much of what she requires for this Plan is derived from the initial draft of our Release Notes.
Among the many improvements she has ushered in has been pushing my product team to better connect the dots around product/feature positioning. For example, the work we do to create testable hypotheses further upstream in the product discovery and early development process were all but lost by the time we delivered the working solution. But that is valuable information that needs to be communicated to customers and end users.
Plan of attack
We generally organizes topics in our Release Notes like this:
TABLE OF CONTENTS
About the Release Notes
Release Overview
End of Life Announcements
Enhancements
- Major enhancement
- Customer facing notes
- Content-marketing fodder
- Internal-only messaging
- Major enhancement
- ...
- Other enhancements
- Fixes
Known Issues
Getting started was not quite as easy as "Save as, Search-and-Replace" but we had developed a reusable structure for the document that made it easier to produce each new iteration.
Internal first, then external version
I began by creating an internal-only version that contains more information than what was necessary for customers. This initial version provides a diversity of details around each topic and was meant to give our Professional Services and Support teams a better understanding of the impacts, if any for customers.
For example, on the extreme end, I might thoroughly describe the migration steps for users that are transitioning from a deprecated feature to a new enhancement. On the other extreme, I may simply reference existing collateral such as public-facing knowledge articles that are affected by the release and would need to be updated.
I delivered a draft of the Release Notes to the Product Marketing Manager early on so she could start to build the Release Communication Plan. I also circulated it to the rest of the teams to get all the wheels turning for the upcoming release.
More than just an enhancement list
The bulk of the content in the document relates to the product enhancements. Customers (and Sales teams) tend to focus on the shiny new things. I try to accommodate by separating and highlighting the big stories from the much longer list of smaller enhancements.
For each major feature, I started by revisiting the existing customer pain that prompted the product work. Sometimes I even included relevant feedback we received before and during the development cycle.
In describing the solution, I outlined the way the feature is used and included screenshots where helpful. I try to provide at least 1 example to further help orient the user.
With all this information repeated for each big enhancement, the document can often get quite lengthy. To counter reader fatigue, I reuse a consistent layout throughout this part of the document and break up the text with subsections, internal links and generous whitespace to make it easier to consume.
Updates to primary customer narrative
Along with the general description of the major and minor features included in the release, I also posted refinements around our main use case to help the Content Marketing Team rework their editorial calendar to fold in new blog posts, videos, and other collateral related to the release.
The internal notes and supplemental use case-related material is helpful for connecting the dots between customer needs and shippable products but is ultimately stripped from the final, external-facing version of the document.
The impact
By most measures, my turn in the driver's seat did not negatively impact our process. I was happy to have made a few, incremental enhancements and as with most product efforts, will be looking for feedback and validation from all stakeholders in the days that follow.
We will go through several internal iterations of authoring and review the Release Notes before we finally publish it externally to customers, concurrently with the release going live. Often, we will work to refine the Release Notes up until a day or two before the release as last minute details are being ironed out. The finished version is deployed on the company website with any number of links from within the product, from support documentation, from the marketing site, and from outbound promotional emails.
Customers have responded positively to the level of information we provide in our Release Notes. I suspect we will eventually move away from the traditional PDF document to a more fluid web/mobile publishing solution. Additionally, we are starting to favor short videos to introduce each major enhancement but they take longer to create and are more difficult to update if/when the screens/pages change.
Look for more reports from theProductPath around product releases, the PM role, and product culture 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
Unveil new product at company event
In recognizing the work that all the departmental teams had contributed to create this novel product, I decided to orchestrate a group presentation to roll out the new offering to the entire company.
The Product Decision: Preview the new product in a group setting where each department contributes to the larger story.
Flickr image source: http://tinyurl.com/obvs3hc
In recognizing the work that all the departmental teams had contributed to create this novel product, I decided to orchestrate a group presentation to roll out the new offering to the entire company.
I really enjoy our Release Previews. These are monthly get-togethers I created to have the Product team demonstrate, to the entire company, the latest, shippable product updates and enhancements. These meetings are intentionally distinct from the less formal Sprint Review, typically led by and targeted at Engineers.
That is not to say that Engineers are not part of the Release Preview - actually they are often featured as we are showing off their handiwork in most cases. But the broader messages we deliver to the company at the Release Preview are more value-driven, as in what value are these updates going to provide to our customers and to our own business?
We all know it takes a coordinated effort to build and release new products. During the Release Preview, I try to make sure we recognize everyone who contributes to our incremental progress and that goes well beyond Product and Engineering. But this was not our standard release.
This was the official launch of our new Reference App.
What drove this decision
This was a major achievement for our company and I wanted this particular Release Preview to stand out from the rest. After many months of planning, development, testing, and customer validation, we were ready to unveil a unique new offering that would differentiate our company - and it was important to me and the team that everyone in the company appreciate the collective accomplishment.
The decision: Preview the new product in a group setting where each department contributes to the larger story.
More important than getting everyone up to speed on and pumped up about the new product, I wanted them to all to understand and appreciate the work that all of us had done to make it a reality. We had shown prototypes of the product many months ago and despite small, periodic updates, many in the company had all but forgotten about it.
In the reminder email I sent to the company days before the event, I emphasized how this particular Release Preview was going to be an extravaganza. Now it was time to put together a presentation that lived up to the hype.
Plan of attack
The highlight of our Release Previews are most certainly the product demonstrations. But as I mentioned before, we are very prudent about wrapping those demonstrations with stories about the value that is ultimately delivered to the end customer. This presentation would be no different but the story would be larger and all-inclusive.
Recount How we gOt here
To start things off, I asked our head of Research to provide the back story. This app came out of one of the best customer research initiatives we had ever run and I couldn't think of a better way to set the stage. Straight from our customers' mouths, we heard about the struggles they had been having with our platform. Over and over, we were told the same thing - you have to give us more visibility into what's going on.
We listened, we prototyped and we validated. The reason I felt so confident in this presentation - and in this new product - was because it was practically dictated to us by our end users.
Get representatives from each department to contribute their parts of the story
Then, one by one, I had representatives from each department stand up and speak to other facets of the product.
Professional Services described the lengths they would go to just to provide a makeshift remedy to the customer's visibility problem.
Engineering and Ops took turns talking about the speed at which we would be able to deliver updates to the product and how much our entire deployment had improved as a result of launching this app.
UX gushed about how the new app leveraged a recently developed component library and how it help to launch a new UI paradigm for the company.
Sales and Marketing weighed in with the overwhelmingly positive response they were getting from the early previews we had been sharing with prospects and customers.
And so on. By assigning each of them a dedicated speaking role and by giving all the contributions equal weighting, I was able to relate a shared victory for everyone.
GET THE CEO TO WRAP IT ALL UP WITH A ROUSING FINISH
I would have been happy enough with just the departmental contributions, but to end on an even higher note, I asked our CEO to supply his own thoughts on our newest product. In a brief but stirring, unrehearsed speech, he shared his appreciation for all our hard work and for the company-wide commitment to product innovation.
It was well-received by all.
The impact
To say the Release Preview went well would be an understatement. We had the largest employee turnout ever for an event like this and I received a great deal of positive feedback afterwards. One of the recurring messages was that we might want to reserve additional, spillover conference rooms in the future to accommodate more of our folks in the office!
I thanked all the speakers individually for their participation and gently reminded them that we still had more work to do to make the official launch a success. At the end of the day, with all the solidarity we generated, I couldn't help but feel that success was, if not inevitable, then certainly more attainable.
Look for more reports from theProductPath around product reviews, releasing products, and product culture here on PM Decisions.
More articles from our blog PM Decisions
In recognizing that many of the decisions we had made over this past year were not driven by or supported with real evidence, I decided it was time to change how the Product team gathered and used data in our processes.
The Product Decision: Confirm with the team exactly what data we were missing and what we would need to do to get our hands on it.