Reach out to the local product community for growth

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

After a year's worth of lessons learned from all the good and bad product decisions I made as my company's Head of Products, I recognized that I would need even more help from the larger community of Product people in the months and years ahead.

As I learn more about what it takes to be a skillful Product Manager, I am continuously humbled by how much more there is to know. I try to expand my understanding by consuming product-related books, articles, podcasts and the like, but I have really come to appreciate in-person exchanges with peers of all experience levels.

And I am fortunate enough to live and work in a large enough metropolitan area to supply many hundreds of these peers. I had only begun to explore the human resources available in this city since moving back several years ago and I am now intent on fully tapping into this fertile (and accessible!) product population.

What drove this decision

I believe that if you actively look, you can always find opportunities for growth, both in your own personal career and with the teams with whom you work in your organization. I was actively seeking both.

I found myself craving fresh ideas and new resources. I wanted expert guidance from outside the company to grow my own skill set as Head of Product - and I would be growing my own Product Team at the same time. It was clear to me that, to improve my prospects, I should better connect with the product community.

The decision: Advance my own professional product capabilities and better address the expanding needs of my company by tapping into the rich pool of talent and experience all around me.

In my own observations over this past year, I began to realize just how large the local Product community was and how fast it seemed to be growing:

• Most of the 30+ new PMs I met seemed to have their own circle of peers with little respective overlap among them.
• My own inbox had accumulated a plethora of local, product-related new stories that would make it seem like this city was a breeding ground for "successful" product startups.
• And one of the local meet ups in which I regularly participate reported to have over 1,1,00 members (although no more than 60 or so ever showed up at a given event.)

I was determined to infiltrate this sizable community using a number of different tactics to track down the right resources to help me with my own product plans.

Plan of attack

I had already put in a lot of effort over the past year, trying to extend my network of Product Managers, both locally and long-distance. But most of those encounters had been introductory and brief. In this new campaign, I had much more specific intentions and would need to precise.

Proactively expand my personal network of product people

One of the activities I enjoy is sitting down, in person, with Product folks I've never met before. And whenever I come in contact with any smart person, I try to make a point of asking them if they know and would introduce me to good Product people.

This past week, I got introduced to a senior PM who is working right up the street from my office. We met for a quick chat over coffee and immediately hit it off, finding common ground with familiar product stories from our respective day jobs. It turns out we were both connected to some of the same people in the community, but he also acknowledged the need to proactively reach out more to our peers. Despite the overlap in our mutual professional networks, the proximity of our offices, AND the fact that I had recently attended an event in his company's space, we would likely never had otherwise met!

This meeting confirmed for me that, if I wanted a potent peer group to draw upon, I would need to drive the outreach myself and continuously build my network the old fashioned way.

Start recruiting for a new PM to join the team

For too many months now, I had been struggling to balance my strategic product work as an executive in the company with the day to day story-level work as a Scrum Product Owner for one of our Engineering teams. I needed to offload the latter so I could better concentrate on the former. In short, I needed to hire a new team member to free me up.

So, with this in mind, I went back out to the community to talk to current job hunters. In the span of a single week, I tracked down four Product Managers who were all looking for their next gig. Two were pursuing senior roles and two were focused more on entry-level positions.

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

I inquired about the state of the job market and their own personal challenges with finding good opportunities. I tried to get a better understanding of what I would be competing with compared to how other companies were hiring. I wanted to understand whether or not the recruiters were effective. I was also curious about the different interviewing techniques they had encountered.

As a result of these discussions, I was a little less optimistic about my chances of hiring my new PM. These were talented product people and for different reasons, they had all been struggling more than I would have expected. In the end, I would have to adjust my own expectations and prepare for a longer recruiting campaign.

Create my own discussion group for practicing PMs

Product-focused community events seemed to be proliferating. I had attended recently a new Product meet up nearby that was just getting off the ground. I tracked down and spoke with the group's organizers to get a better sense of what they were trying to offer to the local community. This week, I ran into another, would be event organizer who had similar plans for launching his own product-specific get-together. Ultimately, these event organizers here in town are increasing the number of opportunities for Product people to engage with their peers. I certainly appreciate those efforts but still felt like there was a gap around engaging in more personal interactions on a regular basis.

these event organizers here in town are increasing the number of opportunities for Product people to engage with their peers.

I will certainly continue to attend and support these product events, but I had been thinking about creating a very different forum. So, in this past week, after several months of planning and preparation, I successfully piloted a new, unique gathering with a small subset of local Product Managers of all experience levels where peers could comfortably share their product-specific stories.

For this initial meeting, I hand-selected a small number of PMs who I had met in my travels over the past year but who, for the most part, did not already know each other. But what they have in common are a sense of modesty (no giant egos), a passion for product development, and intrinsic curiosity - and I found that that set of traits ultimately made the group-based conversation easy, inclusive, and informative. At the end of the night, I walked away satisfied with the outcome of the pilot meeting and now am encouraged to extend the experiment next month with an even larger group of like-minded participants. 

The impact

After a year of writing about my Product experiences, I am still surprised by the sheer breadth of this role and that awareness continues to be reinforced as I speak with more Product Managers. This past week, I chose to engage with the larger community of Product people outside my company and outside my existing professional network. As I look to broaden my circle of peers, I am taking advantage of opportunities to grow my own skills and to grow my company's Product team.

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

More articles from our blog PM Decisions

Call in reinforcements to advance product initiatives

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

In recognizing that my internal team members did not have the time and/or expertise to help with a few of our upcoming and impactful product initiatives, I decided to reach outside the company and use trusted resources to temporarily expand my team.

My team has been working at full capacity and is focused on the exact right priorities to continue delivering strong product releases to our customers. There is always more work to do though and sometimes business priorities stretch beyond the team's existing capacity.

There are also budget constraints that are preventing me from expanding my team in a way that would help me address the projects that have bubbled to the top of the company's wish list.

What drove this decision

Good problem solvers can find creative ways to get around roadblocks. I was grappling with a backlog that was starting to look increasingly daunting and could not rely on the familiar and dependable resources that were tied up with other important work.

So I took some time to review the most pressing items and determined that there were opportunities to make short-term progress that would relieve a bit of the pressure. We could find the resources just outside the company's borders and engage the expertise we needed to catch up.

The decision: Recruit available experts from the company's extended circle of trusted colleagues to help tackle a few pressing product engagements. 

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

We all know smart, dependable people and we try to hire them to permanently join our teams when we have the chance. But these are highly sought-after resources and it's not feasible to hire all of them - how many organizations need 5 senior-level specialists in given functional area? And besides, many of them have already been scooped up by other lucky companies and are happily employed in good positions.

But sometimes, you can catch these folks between gigs and if the stars are aligned, you will have the opportunity to pull them into your group, even if it's only for a brief period of time. I was fortunate enough to have several of those opportunities at the same time and decided to act so I could move forward with my product plans.

Plan of attack

I had been mentally cataloging important projects that were product-related but would not be easy to fold into the main product work stream. Most fell somewhere between must have and nice to have. So to improve my chances of being able to outsource these initiatives to interim resources, I adjusted the scope for each by decomposing larger efforts into smaller increments with shorter iterations to better accommodate less predictable schedules.

As I continued to network with smart product people outside my company I had been on the lookout for available resources with the specific projects in mind. This week, I was able to pull in some strong people to tackle a few of my projects. Coincidentally, each had recently switched into job hunting mode and were delighted to have some part-time assignments to fill the gaps between recruiting activities.

I seized the moment(s) and put them to work immediately to start these three projects:

Build a plan to move from proof-of-concept to prototype

There is a new product proposal that has been gnawing at me for the better part of a year now. I've written about it before (see here) as it continued to gain steam (see here) despite my attempts to slow it down (see here).

This is not the time to argue the merits of this particular proposal but in the spirit of compromise, I have agreed to take the next step in building a true working prototype from the previous proof-of-concept. I was prompted more by the additional learning we could achieve around the technical feasibility than I was in gathering important user insights from an interactive, UX prototype (that would most certainly come later).

I found a talented and credible Product Manager to lead this technical prototype project and paired him up with an expert from one of our technology partners as well as with one of our own Engineers. Collectively, we reviewed the project's scope and made only a few small tweaks to build a 30-day plan that was mostly likely to deliver the outcome.

Revamp product documentation

I don't think I'm stretching the truth when I say that the Product and Tech teams have collectively stepped up our game this year. In addition to reducing the duration of our release cycle to deliver more updates more frequently, we have also focused on pushing out more high priority feature enhancements that are based on direct customer feedback.

What we haven't done well is keep up with all the supplemental collateral that typically accompanies product releases.

What we haven't done well is keep up with all the supplemental collateral that typically accompanies product releases, most notably our official product documentation. There are, I'm ashamed to admit, deficiencies in our collection of knowledge articles with out of date material, flimsy coverage of major components, and complete documentation gaps around key new features.

So I asked a really smart person to help us out. She came in, took one look at our Knowledge Center and decided she would do more than just fill in some obvious gaps. I had asked for help in getting the team caught up - what I got was a proposal and estimate for overhauling the whole depot. Her plan was so impressive that it took me no time to get the entire project approved.

Analytics roadmap

Several weeks back, I had pulled in one of these same folks to help me think through an analytics-related offering. The response to that deliverable had been overwhelmingly positive, both internally and with customers. Based on that success, I reached out to her again and asked for assistance in mapping out a high-level plan to get us to the point where we could actually produce those results in a production environment for customers.

She was the domain expert and needed little support from me other than to know how best to position the final recommendation and how to apply the appropriate polish to effectively sell it to my stakeholders.

The impact

Eventually, I'd like to expand the Product team to be able to tackle even more of the "product backlog" but these short-term engagements have allowed me to make some good progress in the meantime. Outsourcing work can be a great tactic when time or skills are in short supply. My own experiences have been positive, but a great deal of that success is directly tied to finding and securing great resources, inside or outside the company.  

Look for more reports from theProductPath around product teams, backlog grooming, and capacity planning here on PM Decisions.

More articles from our blog PM Decisions

Guide and advise fellow Product Managers

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.

So I published my own list.

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

Find a good stopping point for a postponed feature

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

After the principal customer backed off a requested new feature, I decided to quickly wrap up our discovery work.

Large feature requests require more time to plan and necessitate more resources. Collecting and sorting through customer requirements may stretch out over weeks or even months. And once these initiatives get going, they can gather momentum making it more difficult to shelve everything when the team's priorities change.

What drove this decision

One of our largest customer had asked us to help them with a problem that was tied to how they were using our software. It was a new problem for us but one that we felt would likely benefit other customers.

We had acquired a solid list of initial requirements but we knew better than to rely on only 1 source. So the Product team started researching the similar needs of other customers to begin the work of scoping out a new feature.

Not long into this effort, the original customer reprioritized some of its own, internal initiatives. The urgency around this problem diminished and the feature request dropped much further down the list. 

The decision: Suspend ongoing product discovery and shore up the current state of requirements.

I wanted to make sure that if and when the feature came back around, we could resume quickly and regain some of our initial velocity. We had made good headway and I needed to preserve as much of that as I could, especially if a different team would be picking up the feature next time.

Plan of attack

I was confident that the next team to work on the feature should not have to start from scratch. 

Requirements change, technology changes, and priorities certainly change. And I was sure that if we restarted this effort even 2-3 months down the road, we would have to revisit our assumptions. Still, I felt confident that we had been on the right track and wanted to preserve our progress as best I could.

Review the current hypotheses

I started by capturing the hypotheses I had developed around the proposed feature. I made sure to describe the thinking that went into the current hypotheses, to highlight assumptions I was in the middle of testing, and to list some of the ideas I had already ruled out.

Obviously some of these assumptions would - and should - be revisited but the next group would certainly benefit from the validation work I had done for the parts around which I had more confidence. For example, rather than build an entirely new scheduling tool to orchestrate and run a proposed background process, I had intended to leverage one we already had, even if it didn't completely accommodate all of the new requirements.

Create a list of next steps

I was forced to pause in the middle of the feature discovery but I had been working through a rough plan that would have resulted in a path forward. I felt it was important to document that plan, showing where I had left off and where the next team might pick it up and continue. I tried to anticipate and answer questions they might have such as:

• How far into this effort did the previous team get?
• How would they have scoped the work, knowing what they knew at the time?
• What were the dependencies if any that would guide the order of the proposed work?
• Did they identify technology limitations that would have dictated what was feasible at the time?

Preserve the notes in a convenient, accessible place

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

An obvious measure perhaps but I did not want to make it hard for the next team to find my notes. At the moment, our team uses Confluence for capturing early product discovery work. It is hard to believe that we would have moved on to another tool but anything is possible. So I made sure to create prominent links to the repository from Trello, the tool I use to corral Executive input; from Slack, the new tool of choice for our Dev Ops and Customer Support teams;  and in the primary email thread we had been using to communicate with the original customer.

The impact

Part of me feels that there was some wasted effort both in the original work and the steps to wrap it up for a future phase. But that feeling is not as strong as the one that is happy not to have invested even more time building a feature that may have been excessive or unneeded.

With a pay-it-forward mindset, I tried to think about helping the next PM to inherit this feature as I went through these steps. I know I would appreciate someone doing the same for me. And if it is me that opens the product feature time capsule down the road, I promise to be kind to my former self when writing up that experience.

Look for more reports from theProductPath around product teams, feature prioritization, and product investments here on PM Decisions.

More articles from our blog PM Decisions

Getting ready to groom

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

In recognizing that too many of our user stories were not truly ready to be implemented, I decided to revisit the entire path to grooming

For months, I had been watching the Product team wrestle with getting their particular features out the door and in front of our customers. And it wasn't just one PM who was struggling or an exceptional delay in delivery - it was borderline chronic. More often than not, I could trace the issues back to poor preparation by the Product team.

I have been working with our entire tech team to continuously improve our own Agile development process and we certainly have more work to be done. But the problems I needed to address were further upstream, before the stories entered the Engineering and QA queues. The Product team was creating unnecessary thrashing by failing to do our part well. 

What drove this decision

When your product releases are scheduled less frequently (think months apart vs. weeks), there is a greater impact when you miss a delivery date. I was frustrated at having to drop features from a release because they weren't ready or seeing enhancements slip to the next sprint.

And while it is tempting to spread the blame across the myriad variables that go along with shipping product software, I became convinced that my own Product team had to step up to support our share of the contract.

Some product planning failures are easy to measure. Are features not being completed? Are your stories slipping over successive sprints and even releases? Are your Engineers and QA teams stalled waiting for last-minute clarifications around designs and requirements?

The decision: Formalize the team's story preparation process leading up to sprint planning

The bad/good news was that we had accumulated sufficient instances over the past few months to see some a pattern emerging. Early on, we tried using note cards and a whiteboard to better track the larger product initiatives over sprints and releases. This seemed promising at first, probably because the team appreciated an exercise that was both tactile and collaborative. But we ultimately failed to capture any incremental advancement of any initiative using the cards. Moving the cards across the board from sprint to sprint didn't make us better at preparation and worse, this exercise did not help us identify deficiencies in the planning process.

We needed a different approach, one that helped us focus on maturing product requirements BEFORE we gave them to the team. We needed a better product grooming process that preceded the actual backlog grooming sessions.

Plan of attack

The tactics described below were prescribed only for our larger product initiatives and would likely be overkill for bugs and smaller feature enhancements. We began by focusing on the problems that occurred most frequently, then folded in additional steps to mature the pre-grooming process.

STEP 1 - Include the fully baked UX designs 

Perhaps the most obvious problem for our team was that we were often scrambling to get our front-end designs in place by the time the Engineers were ready to estimate the level of effort. We had become less and less stringent about completing the UX work and ensuring that formal designs were attached to a story or epic prior to backlog grooming or worse, sprint planning.

The lowest hanging fruit, then, was to re-establish this specification for all our user stories. Going forward, no stories would be allowed into a backlog grooming session unless the designs were complete. Obviously, there is no real definition of "fully baked" as teams will inevitably tweak designs during development and even testing but this was a relatively easy first stake in the ground.

STEP 2 - Review the acceptance criteria with internal stakeholders

I'm of the mindset that you can never stop improving on your ability to define product requirements. I encourage my Product Managers to continue to work on this skill with each new assignment. But there is an easy to tell whether you are actually improving or not by gauging how often your stories are being kicked back by the Engineering or QA teams.

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

And even if you are scoring well with these groups who are much closer to the code, you probably have other stakeholders inside the company that can help you measure your aptitude. In our organization, the Sales Engineering and Professional Services teams are great early sounding boards. Another important group (for us and most organizations) is the Customer Support team. Each of these groups is intimately familiar with your customer base and can help validate how well you have done in capturing the happy path(s) and the larger set of user variations.

In our updated process, we have a specific gate for reviewing stories or at least the acceptance criteria with our internal stakeholders. This has the additional benefit of not catching them off guard during a Release Preview for example, when the feature is already "complete". 

STEP 3 - Weave in usefulness testing with end users

When it comes to testing products with end users, excuses usually outnumber opportunities. Like most Product teams, we would prefer to have more time to spend with our customers but scheduling these interactions always seems more difficult that it should be. Still, the team and I firmly believe this is a critical part of the grooming process - especially as the requirements and designs come together.

Going forward, we have made this an explicit stage in the lead up to backlog grooming. Of the steps listed here, it is the most challenging to implement but will likely have the biggest payoff. I can think of nothing better for removing doubt and minimizing surprise than having end users validate your product throughout your development process.

The impact

The Product team is still adjusting to the new approach although we all recognize the improvements that will come with better story preparation. We've already seen some of those benefits: in the past few weeks, we withheld a number of stories from backlog grooming that had not met the new criteria, saving us hours of guaranteed thrashing with the Engineering and QA teams.

Additional refinements will be necessary. As we advance and extend our customer research and user testing, we will introduce new gates in an effort to further solidify the product features and push them through our Agile process. 

Look for more reports from theProductPath around product validation, backlog grooming, 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