Create a year-end Product progress report

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

In an attempt to summarize our collective accomplishments over the past 12 months, I decided to create a simple, 1-page chart that communicates the product advancements and highlights remaining product opportunities.

Many people look to the end of the calendar year as a good opportunity for reflection and this is as true in the professional world as it is in the personal one. Twelve consecutive months would seem to provide a sufficient review period for attempting to understand the overall impact of the team's more significant product decisions.

I have previously written here about why I feel the Product Manager has a more pronounced need to establish credibility than most other roles in the organization. It is easy to make grand, sweeping promises but ultimately, a PM and his/her team will be measured (continuously!) by the results they achieve. And even those small victories can be short-lived as the team is pushed to address the next round of challenges.

So, it seems fitting that I take a little time during the last week of the year to revisit those promises I had made and to fairly tally up the "scores".

What drove this decision

In the spirit of transparency, I wanted to conduct an honest assessment of how we did or did not advance the product portfolio and then share that with the entire company. I had established clear objectives at the beginning of the year and now felt an obligation to compare our actual results with those original goals.

I was also hoping to create a new artifact that might even help motivate the teams. Something that said, "Look how far we've come!"  If it turned out the way I thought it would, it could become a new collateral piece that gets the Sales all fired up, sending a clear message to them about how much easier it had become to tell and sell our story to customers.

Above all, I wanted to use this progress report as a reminder to the entire company that we have made great strides together along the very roadmap themes I laid out at the beginning of the year. It turned out that it was also useful for pointing out, even foreshadowing, where we'd likely be spending our time next year.

The decision: Use the familiar customer process as a backdrop for reporting finer-grained enhancements across the entire product suite.

View fullsize

Simplified customer business process

For the past few years, the Product team has been refining our understanding of our customers' core business process. We ultimately captured the process model in a single, clear diagram which we have been promoting and reinforcing with each major release so that, by now, everyone in the company was familiar with it.

This representation of the business process had been especially helpful in orienting the product team's efforts and now seemed to offer the ideal structure for lining up the various product initiatives from the past year. So I thought I would use it as the underlying structure for my progress report.

Plan of attack

Being a fan of 1-page artifacts, I set out to build a single chart that I could use to tell the story of the past year, one that would clearly illustrate our highs and our lows, our triumphs and defeats, our victories -- you get the picture.

Collapse the business process to create a familiar backdrop

View fullsize

Flatten the familiar process for context

I was confident that the process model we had been using for our own internal discussions - and which had been repeatedly validated by prospects and customers alike - would provide the right context for my new chart.

The original process diagram had filled the entire page. I tried to retain the familiar shape of the process but compressed it to fit in a much smaller vertical space. I removed the actor icons but kept the text labels for each step, moving them to the bottom of the new diagram to maintain the various transitions in the process.

Create a simple scale for relative comparisons

View fullsize

Horizontal lines set up a scale for comparisons

Next, I needed to create a way to compare the various product initiatives in a way that my audience could see the respective value of each project as it related to the customer's business process.

Ultimately I created a 3-point scale with the intentionally provocative labels "Poor", "Par", and "Premier." If I was going to use this chart to provide an honest report on how well we did over the past 12 months, I wanted to have a way to communicate where we had done well, where we had fallen flat, and where we were still struggling with mediocrity.

Plot trajectories for each product initiative

View fullsize

Plot each project as a trajectory

With these structural elements in place, I was now ready to add my data to the chart.

Instead of representing each initiative as single points on the graph, I chose to roll up the initiatives under more familiar customer-facing features and plot them as parallel vertical lines. Each feature had a bullet point to show where the feature would have been scored at the beginning of the year. I then extended an arrow from the bullet and the length of each line was meant to show how much we had improved the feature over the course of the past 12 months.

For some features, I stacked more than one arrow if we had taken several passes at it. Some features had no arrows which were meant to show a complete lack of improvement - even more meaningful when they appeared lower on the scale. It was absolutely my intention to highlight these features as ones that would require attention in the months ahead.

The impact

I had no prior experience creating a chart like this or even using a progress report to roll up the results of a year's worth of product roadmap initiatives. I will admit it that it was validating for me to see the results of our collective efforts captured in a single place though I recognize some obvious shortcomings with my approach:

• My chart only has upward pointing arrows - One might get the wrong impression that none of the work we did actually made things worse for our customers - ha!
• My chart ignores all the non-feature work - Anyone that did not work close with the Product or Tech teams might get the impression that this is all we accomplished when the truth is that so much more was done to support our growing customer base.
• My chart only exists because the story is mostly positive - I'm not sure I would have pursued this task if I thought it would have shown us in a bad light.

I'd like to think I'm not purposefully avoiding reporting on any negative outcomes but I knew that I would inevitably focus on those areas that made us look good. In the end, I think this is a fair report and have received similar confirmations from others in the company. I certainly achieved my goal of painting a clear picture for the company and my stakeholders around the improvements we've made from a year's worth of product investments.

Look for more reports from theProductPath around charts, evaluating product portfolios, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Showcase roadmap to advance a large deal

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

To accelerate the largest sales opportunity in our pipeline, I agreed to lead a spirited, product-oriented discussion with the prospect free from any heavy sales pressure.

It is not uncommon for Sales to pull the Product team into large deals, especially late in the sales cycle where there is a need for even greater assurance that we are a vendor on which they can rely. I have developed and shared sanitized, customer-facing roadmaps on many occasions and have even delivered custom product demos to help our Reps close their transactions.

I do have to be careful about sharing too much information prematurely. Even hinting that the product may be headed down a particular path can send an overeager Account Executive spiraling off in a wrong direction. But I do appreciate the positive impact for a potential customer to "be invited to a private meeting with the head of our Product group." I also think it is valuable to assist in efforts like these and to maintain a healthy relationship with our revenue-producing Sales team.    

What drove this decision

 I am firmly against letting any one customer hold sway over the roadmap and my product priorities

I was familiar with this particular prospect - indeed we had all been watching the opportunity progress over the past few months. The use case was squarely in our wheelhouse but the prospect had identified a few specific feature requests that we might not otherwise have delivered in a suitable time frame. And while I am firmly against letting any one customer hold sway over the roadmap and my product priorities, I do believe there is room for a large, active user base to weigh in on decisions about product direction. 

The decision: Demonstrate an impressive pace of innovation through a series of past accomplishments and future intentions and encourage the customer to weigh in on the ongoing roadmap priorities.  

Image source: http://tinyurl.com/qjogg57

Customer seem to love talking about roadmaps. Even when you lay out all the disclaimers about lack of certainty and best guess estimates, there is still enough curiosity remaining to drive a lively conversation.

I don't mind sharing our vision for the products and where I'd like to take them in the months and years ahead. There are certain paths that are quite clear to me at the moment and others that are more directional in nature.

I am also very comfortable weaving a strong product story that incorporates past achievements with current work and that extends into the not-to-distant future.   

Plan of attack

As I mentioned, the meeting was not intended to be overly sales-y but the parties on both sides knew this would be another part of our pitch for their business. I built a product-focused agenda that put our offerings in the best possible light. I accentuated the products and features that were high on their list of needs, starting with items for which we had just completed development and moving to the ones that were still several months away.

Demonstrate A working version of an early prototype 

Previously in the same sales process, I shared some clickable prototypes with this prospect to give them an idea of where we were headed. One prototype in particular was more relevant to their primary use case and the prospect had showed great interest at the time.

The Product and Engineering teams had since made good progress with the development of this feature so I used this opportunity to walk the prospect through a fully implemented version. The feature was intended to be the highlight of the upcoming product release so the demonstration was positioned as an early and somewhat exclusive sneak peak.

Preview unreleased features

Another keen area of interest for the prospect happened to overlap with one of my high priority product initiatives. I had been pushing our internal teams to complete the first iteration of a major component whose full delivery schedule would stretch out for many more months.

It turned out that while this initial cut was not quite ready for widespread use, it was certainly viable for use in pilot exercises like the one the prospect had scheduled. Again, we emphasized the exclusive access being offered and made sure to highlight our company's rapid pace of development.    

Share detailed roadmap of prospect's most requested feature

After completing the feature demonstrations (which were well-received), I switched gears and walked through a customized product roadmap. The prospect had expressed a need for functionality that was not yet part of our product but that would represent a natural extension to the platform.

While I was careful not to make promises about specific dates, I was able to talk through a plausible plan that illustrated the incremental delivery of their requested functionality. 

Unveil results of relevant internal research efforts

In a separate internal research & development initiative, I had recruited a data scientist to help us look for useful and insightful ways to share the data we were collecting around our customers' workflows. She had produced some impressive dashboard-style reports and charts that were scoring huge points with our internal stakeholders. 

So, as the big finale to the conversation with our prospect, I rolled out these artifacts and tied them back to the workflows they would ultimately use in their own solutions. The resulting discussion was quite fruitful for both parties as we collectively described a future partnership filled with great potential.

The impact

The short version is that it worked! The conversation was very productive and we impressed the prospect enough to have them throw more weight behind the initiative. Nothing specific was promised but they did acknowledge our commitment to advancing the products and their unique opportunity to work with us to guide its long-term development.

Look for more reports from theProductPath around product reviews, socializing product roadmaps, and the PM role here on PM Decisions.

More articles from our blog PM Decisions

Fire up the Sales team

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

Unveil new product at company event

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

Deliver a more compelling product status update to the troops

Image source: http://tinyurl.com/p3cc4o6 (Flickr)

In recognizing that our periodic meetings to share our development progress were falling flat, I decided to revamp the company-wide Product Preview event.

For many years, our company had maintained a recurring "preview" meeting where all employees were invited to catch a glimpse of the most recent product developments. At each meeting, a rotating group of Engineers would take turns showing off their team's work, which frequently included partially finished features that often led to unproductive Q&A with the assembled audience.

I believe the original motivation for having these meetings was well intentioned. It can be difficult for other parts of the organization to appreciate the black box that is Engineering. By revealing to the larger group the fruits of all that labor in a product demonstration setting, all interested and affected parties have a better opportunity to stay in sync.

But in our organization, these regular updates from the tech side of the house were not working. It was difficult for non-Engineers to relate to the material. We needed more structure, more context, and a bit more sizzle than you might expect from those who spend the majority of their time with variables, algorithms, and debuggers.

What drove this decision

Image source: http://tinyurl.com/qyhp33b (Flickr)

Engineers seem to communicate best when they're speaking with other engineers. I don't think I'm inviting controversy by stating that Engineers are not the best orators. Public speaking is not necessarily a skill that helps them with career advancement, and perhaps part of what makes this particular field more attractive to them. Either way, a company-wide meeting with an exclusive Engineering agenda is going to have its challenges.

Engineers also tend to have a myopic view of their work. Even when you find a vibrant communicator, they will still struggle to connect their important contributions to the larger picture. To be sure, getting that new feature to work is a great accomplishment (especially when you factor in the additional challenges of having to upgrade to the latest, post-beta, open sourced, cross-platform, fault tolerant, minimal footprint, backward-compatible, mobile-optimized, ...)

But in a larger group setting like this that draws a cross-functional audience, there is an even greater need to tie the product-level work back to the higher-level company goals. I needed to find a way to continue to report on the great progress we were making but in a way that better catered to the entire company. 

The decision: Substitute the Engineering-led, tech-heavy, feature-level demos with a Product-led, value-driven, full on show-and-tell lineup

Image source: http://tinyurl.com/ntevbtd (Flickr)

To clarify, I still want the Engineers to join in. And the meetings would still center on product demonstrations - that is still the best way to share with the company the progress we're making on our products. What I wanted was to tell that broader story, where product innovation is ultimately tied to business value (ours and our customers'). More than anything, I was intent on having the entire organization understand our motivation, what drove our priorities and how we were validating our hypotheses.

Our organization happens to be following an Agile software methodology, but I want to be clear that the show-and-tell meeting I'm describing here should not be confused with the Scrum Sprint Review. There is great value in having Product and Engineering conduct a meeting to share progress, review what was and was not accomplished in the most recent sprint, troubleshoot issues, and critique each team's work (see here for more information on Scrum's sprint preview). In fact, it would not be uncommon to also invite the same audience to the Sprint Reviews.

Plan of attack

After a quick poll of the other department heads, I confirmed the approach and verified that I would not be disrupting any dependencies they had that would have stemmed from the original meeting. And, as soon as I felt confident that the Product team was prepared and ready to take the lead, I cancelled the old recurring meeting, then created a new meeting invitation with a revamped agenda based on these goals.

Review Customer Success from Past Releases

I am intimately familiar with large product efforts that were, at one time, deemed high-priority or "must-haves". But I've also observed that, too often the very next big feature quickly distracts us so that we lose track of what happened with the last one.

I wanted to start each meeting with a brief update about the last release, and specifically what we could report from our customer base. We had been improving the tools we use to help us better measure customer uptake. The Product team would continue to refine these reports to help communicate the return on our past product investments. 

Did we hit the mark on the last release?

• Who was using the new features?
• Who wasn't?
• Were the bug fixes received well? 
• Is the product more stable, less glitchy, and scaling well?
• What else did we learn?

DEMO NEW PRODUCT DEVELOPMENTS AHEAD OF the UPCOMING RELEASE

Image source: http://tinyurl.com/nkk7cpb (Flickr)

For most attendees, the draw of these meetings was still the shiny new features and we certainly wanted to use the opportunity to spotlight all the great work accomplished since the last release/meeting. But the switch to having the Product team members present the updates meant that they were more likely to hear how individual enhancements fit into the larger end user stories, how the updates might affect the configuration and pricing of the products - even how we might alter our product positioning in the market.

We also want to illustrate how the latest changes were building on previous rounds of investment rather than just demoing individual features in apparent isolation.

The Product team is always collecting feedback to validate our efforts but this would not have been the first time the other departments would have seen these product updates. At these Product Release Preview meetings, our intent is to show off features that are complete and already scheduled in the very next product release.

REVIEW THE CURRENT PRODUCT ROADMAP

The Product team has been putting more energy into the roadmap planning process itself and worrying less about adhering to any particular iteration of the roadmap. These meetings proved to be an ideal opportunity to update the company on any significant changes we had made to the roadmap since the last gathering. I intentionally scheduled this topic toward the end of the meeting to time box help keep the interactive conversation focused and productive. 

At this time, the Product team has not committed to publishing a refreshed Product Roadmap at each meeting.

RECRUIT CUSTOMERS FOR PRODUCT RESEARCH

We close each meeting with our continued plea to get everyone's help in recruiting customers (and prospects) for our ongoing product research initiatives. We have found that our calls for help tend to yield more fruit in the larger group setting, especially after delivering a rousing product demonstration. 

The impact

Part of the motivation for these changes was to stir up some excitement around all the great product work that goes on behind the scenes. Celebrating your accomplishments and sharing them with the entire organization is healthy for any team and can really boost company morale. And we certainly achieved that with the new format.

With the changes I made to the agenda for this "preview" meeting, I also helped distinguish these Product show-and-tells from the Engineering (Scrum) sprint reviews. And based on the informal feedback I received, our Engineers were actually relieved that they would not have to present to the group and that they would be excused from even attending the meetings - although many of them still show up and participate!

I consider this particular decision a great success and will share more about the impacts in future posts. 

Look for more reports from theProductPath around product teams, product culture, and product reviews here on PM Decisions.

More articles from our blog PM Decisions