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

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

Reset expectations around Engineering capacity

In recognizing that many of our company's developers had been committed to important engineering tasks unrelated to advancing product features, I decided to clearly illustrate our true capacity for product innovation.

The pressure on a Product Manager can be intense at times. On the one hand, you are responsible for answering the deceptively simple question, "what are we planning to do next?" All eyes are turned to you for long term product strategy and the product roadmap. And as the owner of the product roadmap, you will have no shortage of helpful suggestions streaming in, from many strong voices, constantly weighing in on what they think should be done.

Perhaps just as stressful though, is having to address the related but more nagging question, "why can't we get more done?" This was a recurring question in my company as many stakeholders were eager to see us move faster. 

“Why can’t we move faster?”
”Why can’t we get more done?”

These are fair questions from well-meaning people but it didn't take long for me to realize that there was a fundamental misunderstanding at the senior leadership level about our true capacity for product development. 

What drove this decision

If you are not directly attached in some way to the software development machinery in your company, then chances are you don't have a good appreciation for all that goes into building solid product features. The decisions that are made by Designers, Engineers, QA, and Operations are just as foreign to other groups as the inner workings of Sales, Marketing, and Finance are to us software types. In our company, though, there was growing frustration with the lack of progress being made on the product side.

The software team I joined had indeed struggled, missing targets, dropping features right before a big release, and generally falling victim to interruptions and emergencies. We have a strong Engineering team but a good number of them were being assigned to tasks that, while important to the company, were not contributing to product innovation.

In my new role as PM, I had a plan to begin a new chapter for product development at our company. Success would depend on building credibility early with stakeholders and a big part of that meant resetting some expectations. Specifically, I would need to explain why I would not be able to achieve as much as they had been expecting. I would have to justify why we weren’t able to accomplish more.

Image source: https://www.flickr.com/photos/jurvetson/2292656889

The decision: Publish a straightforward model that would clarify our actual capacity.

Through a number of internal meetings, I learned that members of our talented engineering team had been assigned to work on internal projects such as scaling our core software platform and optimizing our development process. Other team members were allocated to team management or committed to rotating assignments with Customer Support.

The net impact was that the size of our Engineering team had been reduced. The remaining developers were available to work with my Product team on new features but would also have to address bugs that cropped up. Then there were research tasks that did not directly yield new software but would certainly benefit future development. And finally, we had to plan around holidays, vacation days, sick days, and any scheduled technical training.

All in all, there are far fewer available cycles in a Release than one might think.

To clarify our true output capacity to our senior management team, I built a simple scoreboard of sorts for each release that showed how many FTEs were available for product development.

Plan of attack

Normally, I'd relish an opportunity to build some elaborate model but in this case there was no need for fancy diagrams. Instead, I created a simple picture using PowerPoint, similar to the image at the top of this post.

I started by using squares to represent each engineering resource making it easy to visually determine the total number of Engineers on staff. Then, using different colors for each bucket, I identified how many engineers were being assigned to non-product initiatives and labeled each initiative appropriately. I chose to omit specific names in the diagram, even when it was obvious (e.g. team leads).

The result? A clear model that illustrated our company's actual product development capacity.  

The impact

You could disparage this approach and claim that I had prematurely adopted a defensive posture or taken a pre-emptive CYA step. But our senior leadership team was overdue for a reset. In the weeks that followed, in conversation after conversation I used the diagram to remind everyone exactly why we could NOT move faster.

This led to more productive discussions about resource allocation, hiring decisions, and generally rearranging priorities. And to me, those are the right kind of questions to debate.

Look for more reports from theProductPath around capacity planning, communicating with charts, and working with stakeholders here on PM Decisions.

More articles from our blog PM Decisions