Balance give and take, yes and no, push and pull with products

In a week that seemed to bring every form of product choice a PM can encounter, I decided to exhibit strong product leadership on every front.

Most Product Managers are continuously making choices about what goes into the product and what stays out. We use tools like the product roadmap to break down and convey these decisions over appropriately-sized release cycles.

Senior PMs also have to make choices about which Product Manager works on what parts of the overall puzzle and how best to coordinate dependencies across all the pieces to deliver the larger solution in a timely way.

We make difficult choices about what we feel comfortable promising to the Sales and Marketing teams who are busy prospecting for future customers that will bring in new revenue.

And Product Managers have to make critical choices about how to balance the perfectly usable product with what's feasible given the available technical resources as well as other constraints that are also in play.

It is rare, in my experience, that a Product Manager is faced with all these choices in the span of a single week. This was one of those rare weeks for me.

What drove these decisions

We are closing in on the end of the calendar year and that is affecting each department differently:

• Can we close these deals before the quarter ends? Our Sales team is a rush, scrambling more than normal to close their deals. Sales leadership is pushing everyone to go a little faster and be more aggressive with their prospects.
• What can I tell my customers who have "urgent" questions about next year's product developments? Our Professional Services and Support teams are trying to work with existing customers who can't seem to wait for the future product enhancements that might be just around the corner.
• How will we grow the Product and Tech teams to meet the demands of the business? Our senior management team is trying to lock down schedules and budgets in the planning for next year, hoping to align individual departmental recruiting and hiring plans.
• Did we get as far as we wanted? And of course, my own Product team is doing some reflecting on our efforts over the past year as we think about changes we want to make in the coming year.

As I said before, this is a unique time of the year where Product Management, like other departments, is feeling an increase in pressure to respond to our customers, our fellow employees, and our stakeholders. But I felt more impact during this particular week as I fielded product-related solicitations from every corner of our business. 

The decision: Use each and every opportunity to demonstrate solid product governance.

In a recent, rather insightful exchange with a PM peer, I was made even more aware of how broadly the Product team's decisions will radiate outward to the rest of the organization. For example, the product priorities can influence deals in the Sales pipeline, ideally in a positive way, as we build trust with prospects around the upcoming roadmap commitments.

The choices we make will also impact how the Professional Services team and the customers do or don't utilize our products to solve their problems. In too many situations, I have seen product/platform deficiencies spark some creative workarounds, many of which create even bigger complications for me as I inevitably roll out future product enhancements to address the feature gaps.

I was made even more aware of how broadly the Product team's decisions will radiate outward to the rest of the organization.

Our decisions can also lead to new technical debt (knowingly or unknowingly), that will someday impact downstream engineering work.

Like every Product Manager, I carefully weigh the impact of my decisions with exactly these outcomes in mind.

Plan of attack

While I was still intent on pushing forward with my own Product agenda, I tried to be conscious of the respective priorities and stresses of each department with whom I came in contact. In each circumstance, I looked for a way to balance the needs of all parties while still doing what I thought was best for the long-term health of our business.

Along the way, I also found opportunities to revisit and improve my own methods.

Give a product, take a product

This week, I passed over the ownership of a new product to a very capable PM and was thrilled to see him deftly receive the hand off. It was a big relief for me to be able to move the effort safely off my plate, but it was even more satisfying to watch an experienced Product Manager run the entire exercise without any oversight. I am confident that this decision will help the company deliver the new product to customers according to the original plan.

During the same week, I pulled a separate product initiative away from a different PM on my team, partly because I needed him to focus on (and finish) a separate project. But I was also concerned that the initiative was not advancing at a good pace, which was going to negatively impact a large percentage of our customer base. This was the harder of the two product ownership decisions, but the needs of the customer ultimately prevailed.

Saying no and saying yes to customers

This week, Sales pulled me into two high-profile customer conversations where strategic outcomes were partially dependent on release dates outlined in my product roadmap. In the first case, I knew our teams were ahead of schedule which prompted me to confidently confirm to the customer, "yes, we will absolutely hit those dates for you."

The second conversation didn't go as well. I began the discussion by asking questions meant to help me discover exactly what this organization thought they needed. It didn't take long for me to recognize their request though, as it frequently shows up in competitive sales situations as an obvious land mine strategically placed by another prominent vendor.

My attempt to point out to the customer that they had been misled was not well received. They persisted by parroting their "needs" to us and pinned me down by asking if I had plans to deliver features to address their problem. I said, "No, we do not currently have such a feature and I have no plan to deliver that in the next year.  Specifically, it is not on the product roadmap."

After that call ended, I found myself in some heated discussions with our Sales team who was not altogether pleased that I had been so blunt with the customer. I reflected on this for some time and later came back to apologize and to say that I would try to soften my answers on future such calls. Indeed, I would need to learn better ways of saying "No."

Push and Pull Priorities

This week, I also sat with the CTO to have several talks about our product plans for next year. We agreed that the teams would need to spend more time on product deficit in the months ahead but recognized that it would impact our ability to keep up the pace of innovation in terms of customer-facing features.

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

In a simple whiteboard exercise, we were able to list more than 20 separate initiatives that needed prioritization and ultimately reorganized a number of the items on the product roadmap.   

Some of the short-term, scale-related items would ultimately pay off for all of our customers even if they couldn't be demoed in a webinar or training course. Many of these projects were overdue as parts of the underlying platform were in need of repair or rebuilding to handle the next wave of new users. 

I can appreciate the need for ongoing investment in the plumbing, in the supporting architecture and all the frameworks on which our products are built. I understand how the resulting performance of the applications contributes to a positive user experience. Still, it can be hard to sell that to the other stakeholders in the company who can't readily appreciate the improvements. Part of my job in the coming months would be to help extol the virtues of those investments to impatient parties who crave more visible features.  

The impact

I left out many of the other events of the week that included making some necessary personnel changes, planning for an upcoming office space shuffle, and recovering from the annual holiday party. But the net impact of the decisions I described above were ultimately positive for the company. I am confident that we will end the year strong and will have an even better, more productive product year ahead.

Look for more reports from theProductPath around capacity planning, managing stakeholders, and PM credibility here on PM Decisions.

More articles from our blog PM Decisions

Wind down current product initiatives before starting new ones

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

In recognizing that the Product team would not have the capacity to launch any new projects in the weeks ahead, I reassessed all the in-flight work to identify lower priority items that could be put on the back burner.

I believe that inside most successful Product Managers there is a solid Project Manager. After all, what's the point of being able to identify the right features to build if you can't then decompose and schedule the work in a realistic way?

I was certainly drawing from that particular skill set as I reviewed the list of projects that we currently had in motion. But instead of slotting in new tasks, I was focused on capacity planning and looking for ways to reduce the overall workload.

What drove this decision

There are any number of reasons why a team might take on more work than they should. Many of us will simply raise our hand to help when we hear about something that interests us. For example, an Engineer is easily tempted to spend time poking around with a cool, new technology. It is not uncommon for small research stories to grow as you uncover more details. Sometimes small projects get early traction and begin to snowball quickly. Then there are those urgent fires need that to be put out but which ultimately take you in unexpected directions.

I will take the lion's share of the blame for letting our teams get a little carried away over the past few months. Like the Engineer who latched on to it, I was also intrigued about one of the tech-related research projects. And like the Product Manager who had been working on an important feature, I was also curious about we could extend it beyond the original scope. I could argue that these, along with all the rest, were good-sounding and well-intentioned projects.

But, in thinking about the future, I knew I had to revisit the current project mix and better position us to take on the next round of work.

The decision: Find good stopping points for some of the projects in motion to clear the path for new initiatives.

The teams only have so much capacity and the calendar is still a fixed constraint so the next best option is to revisit scope. In some ways, though, this was an easy exercise.

Some of the projects had gotten long in the tooth and I could tell the enthusiasm had started to wane. Always conscious of team morale, I knew I could reassign those folks to different projects. In other cases, I needed to get straying efforts back on track or to achieve some closure, so I created some break points.

Plan of attack

I was looking for simple criteria that helped me pick new projects over existing projects. In most cases, that came down to determining when each initiative would like return value to the business. With each project I wrapped up, I was able to increase our capacity to tackle new stuff.

Complete a year-long drive to finally get over the goal line

I started by addressing a particularly problematic project that had stretched out for far too long. In fact, this particular enhancement had been stuck at 95% complete for almost an entire year and everyone was eager to see this finished.

Product and Engineering had completed their pieces many months ago but were now paused indefinitely as an absurd number of weeks had passed without any forward progress. The effort was blocked, waiting on our Operations team who had been struggling to prioritize the work. Unfortunately, I had no more control over the Operations department than any other and would need to be creative in how to apply pressure.

I tried using guilt mixed with a bit of positive motivation and even some old-fashioned horse-trading.

So I tried using guilt ("c'mon guys, this has been overdue for far too long") mixed with a bit of positive motivation ("our customers are really looking forward to this enhancement!") and even some old-fashioned horse-trading ("how's about I offer up some time in the schedule to tackle this other project you care about in exchange for knocking this out?"). In the end, I exhausted some personal capital to get this done but was happy to finally see it on a path to completion.

Scope back a feature enhancement that had expanded over time

In another scenario, I zeroed in on another feature enhancement that had experienced some scope creep. The PM had started out with good intentions but had augmented the work over time as he found more and more technical debt to tackle.

Now as we realized that the latest round of proposed changes would push us well into the new year, we culled the core improvements from the larger set of stories and chose to deliver a smaller, but still substantial upgrade to our customers. This decision contributed some breathing room to the roadmap, freeing up some Engineering resources to work on new work in the weeks ahead.

Conclude a key product prototyping effort

Several months earlier, I had recruited a talented, external resource to build a data analytics prototype that would enable us to conduct some product discovery work with our customer base. In doing so, we secured a trial license to a third-party business intelligence tool which would expire in the next week. That provided a natural stopping point and a good motivation for wrapping up that initiative.

I worked with the contractor to put some final polish around the prototype and together, we delivered a final presentation to my CEO and to an influential external party. After those successful demonstrations, we put the prototype on the shelf with the expectation that we would be able to bring it back at any time, as our needs (and budgets) changed.

Pause the team on new research proposals

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

I am a big fan of continuous research and development and we are not short on new areas to explore. It is entirely possible, though, that I let us get ahead of ourselves by encouraging folks to come up with new product and technology ideas to research, with the thought of being productive during those holiday weeks at the end of the year.

Now, I had to reset expectations a bit. As gently as I could, I conveyed my appreciation for everyone's enthusiasm and commitment while at the same time explaining that we would have to table some of the research proposals for the time being.

The impact

There is nothing particularly special about cleaning up projects at the end of the year, but the cumulative slow down in many areas of the business provided me with a great excuse to pare down our workload. I made sure we did not simply abandon projects mid-stream. I also did not want to give anyone the impression that we had simply become distracted by something more exciting. I tried to help the teams recognize that priorities were always changing while at the same time, emphasized the value of achieving closure.

The net effect of these decisions is that I had fewer projects in motion and more Product and Engineering capacity to head into the new year.

Look for more reports from theProductPath around roadmap planning, product investments, and capacity planning here on PM Decisions.

More articles from our blog PM Decisions

Convey the Product Vision to outside influencers

To do my part in helping promote the company with external stakeholders, I decided to tune up my product presentation to deliver a compelling blueprint for the future.

An early stage company often needs to do more than simply sell and support its products. For instance, there are occasions where larger and longer term plans must be discussed to advance the business through the help of customers, partners, and investors.

As the Head of Products, I often participate in these discussions, usually to tell our unique story from a product perspective. My contribution is relating all the progress made over the past weeks and months to the broader and still unfolding product narrative that will continue to propel us forward in the years ahead.

What drove this decision

With all the hyperbole about taking it to the next level, I rarely see anyone writing about what you do when you get there. There is, of course, the want to celebrate the achievement but that is short-lived and you usually don't rest there for very long. The same energy and passion and drive that got you and the team to this point is what will ultimately compel you to keep moving forward.

My company had reached another stage in its growth and it was time to turn our sights to the next plateau. New players were now starting to take an interest in the company and it would take additional time and energy investments on our part to engage with them.

It should be no surprise then, that in this situation, I would turn to the same tools and tactics I had used to help get our company this far. It was clear to me that, going forward, I would be telling and selling an even larger product vision.

The decision: Prepare and pitch a more strategic product roadmap that could accommodate a broader range of business conversations.

The product roadmap continues to be my go-to asset for constructing full and lively reports, especially with those unfamiliar with our business. I continuously tweak our roadmap, not just to reflect the evolving initiatives and priorities but also to help me tell better stories.

Every so often, I am able to produce a rendition of the roadmap that has just the right amount of fidelity. When that happens, I can communicate equally well with everyone from Engineers to Board members. This was one of those occasions where details about individual features or shorter-term enhancements would be folded into larger themes that stretch out for many months and clearly connect parallel product initiatives.

Plan of attack

Over the past year, I had been more tactical with my product plans, mostly with the intent of rebuilding credibility with the other departments in the organization. Now, I was focused on communicating our product direction to audiences outside the company.

Highlight product advancements to strategic partner

My first opportunity came in an early stage discussion with a new partner. This group was more familiar with the general domain, our specific problem space as well as our closest competitors. So there was no need for me to start all the way back at square one. They would understand how the pieces of our platform fit together, where our ongoing innovation was helping us take a leading position in the market, and how we were preparing to address weak spots in the product.

In covering the roadmap, I stepped through a number of the major past and future milestones to highlight where this partner could "plug in" and expand the value for our joint customers. This tailored view of our company's go-forward product plans ultimately helped them construct a companion roadmap for a strong joint offering. 

I found this conversation to be very productive as little time was wasted covering small details. Instead, we were able to focus on a series of touchpoints around which a mutual partnership could be developed. 

Communicate rate of progress to potential investors

anytime I find myself in front of investors, I try to emphasize the current product returns realized from past investments.

My next challenge was to use the same roadmap material to build a story that communicated how recent product advancements had directly contributed to the best year in the company's financial history.

The first part of that story was tying important customer victories to key product milestones in an attempt to prove some level of correlation. Indeed, we had prioritized some of our work over the past year to help advance large deals in the sales pipeline.

More than that perhaps, I wanted to communicate that we felt we had nailed the product-market fit and that customers were more regularly landing directly in our sweet spot.

And anytime I find myself in front of investors, I try to emphasize the current product returns realized from past investments. This audience, more than any other, responds well to proof around ROI.

Demonstrate domain expertise and solid product planning to an unacquainted party

The last test was to engage a new group that had no prior contact with our company and no exposure to our particular problem space. For this discussion, I chose to deliver an expedited product overview that highlighted achievements from the past year. My goal was to try to condense the past 12 months and past 5-10 years into a 45-minute presentation - without losing my audience.

Because I didn't know how long I would be able to hold their attention, I decided to focus on how good we had been (and would continue to be) at product planning. I wanted to show how well we understood our customers' problems and why we were confident that we hold our place as a leader in the market.

I was able to underscore this by calling attention to a few parallel development threads in the roadmap that had recently converged to deliver big payoffs for our customers.

The impact

I received positive feedback from participants in all three meetings over this week. Ultimately, I believe the outcomes were largely driven by the preparation time spent on the roadmap material itself. I have been able to get a great deal of mileage from my product roadmap by making sure that it clearly communicates product intentions, that it justifies product investments, and that it ties these investments back to actual customer needs.

Look for more reports from theProductPath around socializing roadmaps, product roadmap themes, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Build the prototype to aid in new product discovery

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

In recognizing that we were finally in a position to start gathering real requirements from a prime new customer, I decided to move forward with building a prototype for a new product offering.

The Product team had known for some time that we had a legitimate gap in our product portfolio around an MS Office 365 Plug-In but we were not overly anxious as it was clear that the gap was not preventing the company from winning new deals. Even though our main competitor would regularly raise the issue with prospects during the sales cycle, drawing attention to our "deficiency", it had never cost us a sale.

The MS Office 365 Plug-In saga continues to unfold...

You can review the entire story through my past Product Decisions:

HEAD OFF A NEW PRODUCT IDEA BEFORE IT GAINS ANY MORE STEAM

CLARIFY WIN-LOSS SPECULATION WITH POST-MORTEM INTERVIEWS

BUILD A QUICK PROOF OF CONCEPT

COMPLETE AN OPPORTUNITY ASSESSMENT FOR PROPOSED NEW PRODUCT

CALL IN REINFORCEMENTS TO ADVANCE PRODUCT INITIATIVES

From the beginning, when this "urgent need" was first identified, I had been steadily pushing back on internal stakeholders (see sidebar). I knew we didn't have the available resources or bandwidth to tackle this and without a line of customers outside my "product door" clamouring to have the new feature, I was hesitant to even start conversations around the Plug-In.

What drove this decision

In the previous quarter, we had signed our biggest customer in the company's history and, in our lengthy discussions with them around their needs, we had identified the (missing) Plug-In as a key, must-have feature.

This one customer, when fully deployed, could have more than 2,000 people using the new Plug-In. Based on those numbers, it seemed reasonable to me that we now had a decent base of users from which we could start to gather some useful insights.

The decision: Complete a working prototype that we could use to drive productive conversations with customers around requirements

I was eager to start talking with and observing real users in the field but I didn't want to do that using the low fidelity and crudely fashioned proof-of-concept we had completed a few months back. It was time to build and start testing with a real, functioning prototype.

Plan of attack

We were still very early in the product cycle for this Plug-In and there was no pressure to cut corners or skip steps in our product discovery process. I wanted to make sure we used a disciplined approach.

In this first phase, we would create a prototype that would give our Tech team more confidence in what it would ultimately take to develop and support such an app AND that would give the Product Team enough material to have meaningful discussions with the first round of users.  

Vet the feasibility of our technical approach with Engineering

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

I had some solid ideas for how to create an initial version of the Plug-In though it was fair to say that we would be forging into unfamiliar territory. The Tech team had never developed this kind of app but we knew we would be getting support from our friends at Microsoft who is one of our key technology partners.

The first step in building the prototype was making sure our team could nail down some of the technology challenges that we would face. For example, high on our list were questions about user authentication, API access, and deployment of the app to customers through Microsoft's "online store".

So, over the course of a few weeks, the team completed a functioning prototype that addressed these areas of concern. Now, more confident that we had cleared the most immediate technical hurdles, I proceeded with getting some internal validation. 

Share the prototype with stakeholders inside the company

I very much wanted to show the prototype to our Sales Engineers. They had always been good product collaborators and certainly understood the broad use case for the Plug-In. I set up a meeting with them and the Product team and with the Engineers to get and record some early usability feedback.

On the way to that meeting, I made a small detour to give a brief demonstration to our CEO as a courtesy “first look". He had taken a keen interest in this initiative and had been stalking me for many weeks. And even though we had only addressed the most simple use case in this iteration, he was very impressed with our rapid progress. My only regret was letting an Engineer run the demo - who uses superheroes for their sample data? Ha!

I should have known not to let an Engineer run the demo - who uses superheroes for their sample data?

We then sat with the Sales Engineers and reviewed our current hypotheses with them. They see much more front-line action with prospects in the sales cycle and helped validate our approach, often tying back to their deals from the past weeks and months.

I then had each of them install the Plug-In on their own machines to test it out. The response was overwhelmingly positive and we could see them already thinking about how they might adjust their standard demo scenarios to incorporate this new component.

One of them suggested they start using the Plug-In immediately to help them with one of their own team activities and I offered to check back in with them in a few weeks to see how it worked for that additional use case. 

Show it to the technology vendor on whose platform our prototype was built

We had invited representatives from our partner Microsoft into our office for a high-level meeting to talk about Office 365 integration among other things. The timing of their visit provided a perfect opportunity for a prototype demo and to show what we had achieved in the past few weeks, with some help from their own technical folks.

After setting up the customer scenario with the group, we walked them through the working prototype and talked through some of the challenges we had worked through to get to this point. The Microsoft team provided additional validation around our approach for the Plug-In and gave us some pointers for how we could move forward. Our remaining questions were captured and would be carried back to their teams to help get us the answers we would need before rolling this out, even to beta customers. 

In the end, I was pleased to know that our partner was ready to help us with next steps. They also expressed interest in the upcoming deployment with our new customer as it would provide a great case study for both us and them.

The impact

With the Engineering team, I was able to work through a few of the big technical unknowns to build a working version of the Plug-In. By meeting with and showing off the Plug-In to a few internal resources, we were able to get some early, but solid validation. And in reviewing the finished work with the vendor on whose platform we had built the Plug-In, we confirmed that we were on the right track in how we were going to deploy and support the new product.

But none of this would be worth anything if we didn’t immediately start validating the Plug-In with actual users. That work would likely start the very next week and is lining up to be the next chapter in this series.

Look for more reports from theProductPath around product validation, feasibility, and product investments here on PM Decisions.

More articles from our blog PM Decisions

Product-ive roadmapping for the holiday slowdown

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

As we head into the end-of-year home stretch and the inevitably slower holiday period, I decided to make some roadmap adjustments to ensure we would finish the year strong.

It is difficult for any team to plan well for last few weeks of the year. Even if your business doesn't align with the traditional calendar year, you are likely to be working with customers, partners, and vendors who do scramble to wrap up their quarters and annual cycles at year's end.

On top of that, many of your employees are requesting time off from work leaving sizable gaps in the schedule. And you can just give up on trying to arrange any real business-related travel plans, e.g. to visit customers or to conduct on-site interviews.

With all the distractions that come with the holiday period, I began to ask myself how I could make the most of these remaining weeks of the year.

What drove this decision

We had been moving at a nice clip for the past few months. I was proud of the work being cranked out by the Product and Tech teams. We had achieved some good momentum and I was eager to preserve as much of that as I could. Many of the current projects would naturally extend into the early part of next year and I was determined to minimize any slow down around these particular initiatives.

We had achieved some good momentum and I was eager to preserve as much of that as I could.

But I also knew that it would be difficult for teams to coordinate larger tasks if their coworkers' schedules were inconsistent. With all that in mind, I took another look at the product roadmap to optimize our efforts for the last few sprints of the year.

The decision: Line up a collection of smaller stories, projects, and research to advance roadmap initiatives and to keep the teams productive.

I don't want to make it sound like the teams would otherwise be idle. We had just deployed our last major release of the year and I knew we would have some post-release work to tackle. For example, it was going to take some team coordination to gradually and prudently roll out some of the latest enhancements to the full customer base. Then there was the need to respond to users who would be wrestling with the most recent product changes. And of course, we are always prepared to deal with any bugs that may have slipped through.

The real challenge for me was to identify new product work that we could take on and to fit it into our irregular schedule.

Plan of attack

My goal was to maximize the collective team utilization and minimize any dead spots in the upcoming calendar. No one would be satisfied with blatant busy work and yet, it would be difficult to make much tangible progress on any new product initiative. I, more than anyone, wanted to feel like we had been productive during this time. 

I determined that no one solution was going to work so to increase my chances of success, I ended up using several different approaches simultaneously. In the end, I was able to surface a number of smaller-scale projects to accommodate the various gaps in the teams' schedules.

Lay the remaining groundwork for next year's new product offering

Over the last 8-10 months, we had been working on a number of smaller, separate initiatives that were intended to fit together to create a larger, cohesive feature set. However, unless you had been working closely with the Product team, it would be difficult to see how the individual building blocks we had been delivering over many releases were meant to come together. This was the time to explain the broader vision.

View fullsize

I began by updating the product roadmap to illustrate how we would piece together 4 or 5 of the individual initiatives to create a major new offering to be rolled out in the early part of next year. Then, I scheduled new stories that would ultimately combine the separate components into a new whole. I had already convinced myself that this was going to be a thing of beauty but of course, I have been wrong before!

After we had finished connecting the dots (and bytes) and had painted the whole picture, we would be able to move forward by putting it in front of our users. I would continue to validate the new offering by testing it with our internal stakeholders, with customers in our Labs program and finally with prospects in the Sales funnel.

Tee up a list of discretionary items to fill downtime

Without even looking closely at the calendar, I knew we would have a week or so before the start of January where the Engineering ranks would be somewhat thin. My counterpart overseeing Engineering agreed that we could declare a "free sprint" where the developers would have more latitude in how they spent their time in the office.

I had a decent backlog of research topics that I lined up in case the well of ideas ran dry but I was pretty sure the developers would surface their own pet projects to keep themselves occupied. We continue to see some forward-thinking proposals come up through Engineering and I certainly wanted to encourage more of that activity.

I was pretty sure the developers would surface their own pet projects to keep themselves occupied.

There were, in fact, a few out-of-band product initiatives that were already in motion, and all in different stages of completeness. Those Tech Team members that had expressed an interest in exploring extracurricular material had been encouraged to do so with the intention of tying the work back to short- and/or long-term customer value. Based on the success of those efforts, I could easily extend the initiatives and even stage a few more to follow.

Swap in some overdue projects to tackle technical debt

The company has had a banner year in terms of acquiring new customers. But the reality of growing your customer base and increasing the number of users/transactions on your platform is that scale-related challenges bubble to the top. Inevitably, I would need to schedule some cycles for the less glamorous housekeeping activities.

Every software company has technical debt and it requires discipline to stay on top of that debt. I am always grateful to find those few Engineers that appreciate the value of cleaning up and are quick to roll up their sleeves (can you roll up t-shirts sleeves?) and pitch in to help. We would use this end of the year time to tackle a few of these efforts as well.

The impact

It can be tricky for a Product Manager to figure out how to best utilize the weeks at the end of the calendar year. I looked for some small, but important projects that would move us forward but that had few, if any dependencies to avoid schedule impediments.

In using these three approaches: the free sprint, more "groundwork" stories needed to assemble the next product offering, and addressing technical debt, I was able to stock the upcoming sprints with productive work and reduce everyone's concerns about holiday dead time.

Look for more reports from theProductPath around capacity planning, roadmap planning, and managing product teams 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

Initiate a few modest R&D projects

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

Complete an Opportunity Assessment for proposed new product

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:

1. Head off a new product idea
2. Clarify win-loss speculation with post-mortem interviews
3. 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.

View fullsize

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.

View fullsize

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.

View fullsize

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.

View fullsize

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.

View fullsize

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.

View fullsize

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.

View fullsize

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.

View fullsize

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.

View fullsize

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

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

View fullsize

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

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