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

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

Recalibrate product priorities for the next 6 months

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

As we approached the half-year mark, I recognized that I needed to regroup with my internal stakeholders to make adjustments around what we would be delivering for the second half of the year.

You could argue that the half-way point through a calendar year is a somewhat arbitrary juncture, but nevertheless it provided me with a good checkpoint opportunity. Since the beginning of the year, my team had planned, built, tested and delivered product updates through several releases. Before we commenced with the next cycle, I wanted to revisit our priorities and review any significant changes in the business that would require some course correction in the product roadmap.

What drove this decision

I was confident that the Product team had been addressing the full range of demands and that we would continue to balance stakeholders' priorities as we were all committed to satisfying our end customers' needs.

We had already begun to carve out big plans for the next 6-9 months and some of them would require significant investment. I knew we were aligned with individual departments but over time, the various department heads had lost sight of what was most urgent for their peers. It would be more difficult for me to deliver and promote an updated product roadmap without some preliminary group consensus at the topmost level.

The decision: Organize and facilitate a product strategy summit with all the department leaders to revisit and rebalance priorities.

I will be the first to admit that the word "summit" sounds a bit lofty (pun intended) but I assure you this was not some trumped up, off site boondoggle - I'm saving that for my big end of year 1st Annual Product Strategy Retreat.

My goal was simply to get all the department VPs and some key Directors in the same room and run through a formal, Product-focused agenda. I wanted to use the time to review the roadmap choices we had made over the last 6 months (some good, some bad) and continue to push the company to pursue sound product investment decisions.

Balancing 3 related concerns: curb appeal, interior living space, and structural foundation 

In the many discussions I had been having with the different departments leading up to this summit, it became increasingly clear that there was a lack of mutual appreciation, if not basic understanding of what was driving the other departments' priorities. A number of the stakeholders were out of touch.

I wanted to share this insight with the invitees but in a way that didn't offend or alienate a particular group. In the summit invite, I offered the following apartment building metaphor to help explain the different, but complementary perspectives of each group:

Image sources: http://tinyurl.com/nbzkcoz, http://tinyurl.com/pno7n9f

• Sales wants the building to have massive curb appeal, to look good from the outside so as to increase the chances of attracting new customers.
• Customer Success wants all our new tenants to have a smooth move-in experience and to enjoy living in their new home for many years.
• Operations wants to make sure the building itself can safely support all the tenants and their various housing needs.

And of course everyone in the organization should be focused on increasing customer satisfaction as it will lead to renewals and referrals!

Plan of attack

Setting proper expectations: everybody wins! everyone loses!

I started the meeting by setting expectations for the group - which largely meant telling them that no one was going to get everything they wanted. The summit was an exercise rooted in compromise. I told them that it was equally important for them to defend their own priorities as it was to become more aware of what the other departments were struggling with.

The bulk of our time in the summit was spent prioritizing a lengthy list of wish list items. To kick things off, though, I offered an assessment of the past six months to remind everyone why we built the things we did and to get some feedback.

Review the roadmap themes for the year

I first presented the product strategy I had introduced at the beginning of the year that outlined how I would be making decisions for the next 12 months. Specifically, I highlighted the roadmap themes that were established back then and verified with the group that we were still confident in those decision-making guidelines.   

Review 1st six months

Building on the initial validation from the group, I proceeded to show how the recent product decisions we had made were in line with the roadmap themes. This brief, high level review of the advancements we had made in our product portfolio over the past 6 months provided an ideal opportunity to explore queries such as:

• How accurate was the original plan and how close did we come to hitting our targets/metrics?
• Are the major initiatives still on track or have there been new insights that require us to adjust our course?
• What have we learned about estimating work, about dependencies, about our ability to accurately respond to customer demand?

I was certainly pleased to hear the group confirm that the first half of the year was largely productive and that we had been made solid product investment decisions.

First pass at prioritization

From the Trello board I created to capture individual wish lists for the different departments, I pulled the top 30-40 cards to start the prioritization exercise. The first step was to bucket the items into either one of only two lists: High Priority or Low Priority.

This first pass proved to be relatively easy for the group. I was pleased to see the Low Priority list ultimately accumulate many more cards which meant the final pass would be that much easier.

Overall, it was a constructive discussion. None of the participants were particularly unreasonable and did not fight excessively for their own items.  I did occasionally use the following prompt when we seemed to be getting stuck: "Can we get through the second half of the year without spending any time on this item?" That was often the only nudging that was required to properly bucket the topic.     

Crash course on product constraints

I had prepared a break in the summit schedule in case we needed a cooling off period - and intentionally scheduled the catered lunch to arrive during the break. It turned out there hadn't been that much contention so I instead used the break to revisit some of our constraints and to remind the group about why the next half of the exercise was going to be frustrating for all. Specifically, I talked briefly about the following topics:

• Our true development capacity - what we should really expect from the current size and skill level of our Engineering teams. Read more about setting expectations around Engineering capacity here.
• Software's total cost of ownership - how each line of code we add requires more of our company's resources from Product, Engineering and QA all the way through documentation, support, and training.
• Opportunity costs - each time we agree to start building something new, we must recognize how that will limit our ability to respond to the next "must have" requirement (yeah Sales, I'm talking to you!)

I can't be sure if all the messages landed on point with the entire group but it was my meeting and I was going to take advantage of this ideal product soapbox opportunity.  

Final pass at prioritization

In the home stretch, the group now turned its attention to reviewing the much shorter High Priority list (14 items, down from 40). One by one, I went around the table to get individual input. I guided the group by having each of them select 1 primary item and 1-2 backup items.

When we had finished the final pass, we had arrived at a prioritization list that had mutual support from all departments. And I had a clear indication of how I would be adjusting the Product Roadmap for the second half of the year.

The impact

Not only did we finish the full exercise (on time no less) with a shared prioritization list but I was told afterwards by the group members that it was one of the more amicable and productive meetings around product direction in which they had participated in recent memory.

I made it clear to the group that the summit was not designed to immediately produce a new or updated roadmap. It would take me more time to work through the items on the High Priority list and factor everything into the Product Roadmap for the second half of the year. Still, I would like to believe the outcome of the summit extended beyond achieving consensus around particular product priorities. I think it represented a milestone for advancing inter-departmental agreement. Maybe next time, I'll refer to it as a Product Peace Accord.

Look for more reports from theProductPath around feature prioritization, product strategy, and managing stakeholders here on PM Decisions.

More articles from our blog PM Decisions

Pull a large MVP-less feature from the next release

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

In recognizing that an important but poorly scoped product initiative was slipping further behind, I decided to push it farther back on the roadmap.

I would argue that our organization is actually quite Agile-minded but we have more work to do before we can start scheduling product releases in units of weeks rather than months. In our current state, we have to treat releases with a bit more care as they don't come around that often. So when we target a major product initiative to be completed and deployed in a future release, it is critical that we drive toward the date. Any slip could delay the feature by a month or more and that can have significant customer implications.

I had recently given one of the PMs on my team a real juicy assignment. We had determined, through some solid customer research, that one of the core features of the platform was in need of an overhaul. In matching up usage data with anecdotal user feedback, we recognized that the problems would require more than a few simple enhancements. This was indeed a large product initiative and was lining up to be one of our strategic product achievements for this year. 

One of the core features of the platform was in need of an overhaul.

What drove this decision

We had been wrestling with all the usual challenges of developing a new product feature on a tight schedule. Some requirements required further clarification. Web page and email designs required rounds of tweaking and tuning. Plus the Engineers were being pulled away periodically to troubleshoot and fix other, non-related bugs. And then there was the Operations team who had planned a major infrastructure upgrade that created additional chaos, especially as we depended on those same resources to deploy the new feature.

I could go on, listing distractions and blaming other parties. But the number one reason for the slippage was simply subpar product planning. The PM had not done a good job in decomposing and staging the required work. After a few months, we had created some great new software but no shippable product. 

The decision: Drop the feature from the next major product release and reinvest in some proper scoping

About a month before the next big release, it had become increasingly clear that we would not finish developing the feature in time to validate it thoroughly with our users. In our culture, we place a high value on both sticking to our release dates and only shipping product features that are user tested. The first constraint often governs the second.

The decision to drop the feature at this point in the release schedule may have been a bit precarious. But it was really only the first step in a series of related actions that kept the Product and Engineering teams busy for some time. 

Plan of attack

As it turned out, our poor product planning had resulted in even more work than you might expect from what seems like a straightforward decision. We desperately needed to put this particular feature back on the right path but there were now some additional tasks that would enter the work stream.  

REVERT TO THE OLD FEATURE

So confident had we been in our ability to complete this feature (including functional, performance, and user testing) that the team had started dismantling the legacy functionality.

Now we had to re-mantle it. Or more specifically, we had to back out some of the new enhancements in order to restore the old feature. No self-respecting Engineer enjoys this kind of work and indeed it cost the Product Team dearly in terms of credibility.

ADD A FEATURE TOGGLE

In order to preserve the progress that had been made, we invested some additional time in creating a true feature toggle that would allow us to enable the new version for individual customers. This provided us with the option to conditionally test the new functionality, as soon as it was available, with some of our more curious and perhaps more forgiving users.

RE-SCOPE AND RE-PLAN THE FEATURE

The bulk of the work came from decomposing the originally planned feature into smaller stories and creating a revised, incremental delivery plan that would help us deliver a true MVP first and then, in subsequent iterations, a series of progressive improvements.

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

I will not use this report to describe the detailed process of scoping a product feature. There are many good discussions around discovering the Minimum Viable Product or MVP. To be sure, it takes practice to learn how to be ruthless. Good PMs find ways to whittle away at a product or feature until there are no nonessential elements remaining.

But it takes a different set of skills to then carefully plan the gradual introduction of those elements over time. It can be tempting to load up on enhancements, especially as product adoption increases among customers and users. Discipline and care are traits to be nurtured and celebrated in your Product Managers.

RESET EXPECTATIONS

As I mentioned earlier, this feature, when complete, is intended to make a big splash with customers. In making the decision to postpone its deployment, I now had the delicate task of resetting expectations with our Sales team, with Professional Services and Support teams, and with the few customers and prospects we had been engaging with for testing and research.

The impact

The existing customers and new prospects that were pining for this feature were disappointed with the decision to pull and postpone though I believe the blow was cushioned in two ways. First, we notified them of our product decision several weeks ahead of the release instead of only days before or even worse, after the release.

Second, we took care to explain that we did not feel comfortable pushing a significant new product feature without appropriate user testing. Not to say that this relieved all the anxiety but it is more difficult to argue with the choice of product quality over speed to market.

One final note. The Product team did consider moving ahead with a nearly complete version of the new feature and including it in the upcoming release. The thought was that we would have the ability to turn it on for a few, select customers in exchange for some heavy usability testing. I will publish more on that approach in a separate article.

Look for more reports from theProductPath around planning products and releases, MVPs, and product culture here on PM Decisions.

More articles from our blog PM Decisions

Make Product Decisions Like Cagan

Image sources: https://www.flickr.com/photos/68751915@N05/6848823919, https://www.flickr.com/photos/nataliedowne/6446884983, https://www.flickr.com/photos/norue/9625271288

In what many Product Managers might consider an average week, I made three classic product decisions that would make Marty Cagan smile.

After spending more than 10 years in the Product Manager role, I can't actually recall an average week. Perhaps we are attracted to the role for that reason - because it is unpredictable. If it's not changing requirements at one end, then it might be new technology "insights" at the other. The cast of characters we will work with week to week is variable too as new customer prospects enter the picture and compete for attention with existing customers that have their own unending wish lists.

To be successful, Product Managers must be able to navigate these challenges week to week. Good mental frameworks are essential to making sound decisions and to maintaining credibility over time. When you are feeling overwhelmed, however, you may find it helpful to confront the tough product decisions with this deceptively simple approach.

Inspired - How to Create Products Customers Love by Marty Cagan

What drove these decisions

Most Product Managers have run across Marty Cagan’s book Inspired - How to Create Products Customers Love. I consider it a must read for anyone in the general vicinity of Product Management.

Among the many gems in this book, Cagan identifies three fundamentals ways to validate your product decisions: determine what's valuable for your customers, what is usable by your users (not always the same personas as the actual buyer), and what is feasible given the resources you have at your disposal.

These are not mutually exclusive. Whether you're early in your product discovery or tackling a thorny issue for customer 10,001, you need to land on a resolution that best balances these three forces in order to move forward.

Over time, with practice, this starts to become instinctual and woven into your daily PM routine. You may even be surprised, as I was, in reflecting back on an "average" week that there is a very valid reason for why many of your product decisions had turned out so well. 

The Three Product Decisions: Determine what was most valuable for our customers, what was most usable by our end users, and what was most feasible according to our Engineering team.

In this particular week, I made and can highlight three, separate decisions for our product and ultimately, for the future success of our company.  What makes these particular decisions stand out from the dozens I made is that each was particularly punctuated by one of Cagan's three principles. 

Plan of attack

Decision 1 - What’s MOST Valuable

The team had been exploring how we could redesign an existing product feature and was driving that discussion using input we had gathered from rounds of customer testing. As we unwound the different pieces of the story, we revealed the true underlying complexity and ultimately determined that it was too big to tackle all at once.

I decided to break up the larger story into 3 smaller, discrete pieces and sequence the resulting work to deliver incremental improvements over time - a common problem solving approach. But this decision made it much easier for the team to single out which piece would ultimately provide the most value to our customers and, all other dependencies aside, which we would schedule first.

Decision 2 - What’s MOST Usable

In a separate thread, the team was reviewing feedback we received after showing a proposed new design to some of our end users. We had been planning to introduce a completely new design to address some known usability problems with a particularly popular feature.

Few things are more influential for a Product Manager than hearing end users describe how they use, or would use your product to do their job. It was precisely this feedback, straight from our users' mouths, that prompted me to scale back the new design. It turns out that we had been overthinking the problem and could actually deliver a more usable solution with fewer changes (i.e. less work on our end).

Decision 3 - What’s MOST Feasible

Software Engineers like to explore new technology. I know this from having spent the first 10 years of my career as an enterprise software developer. In this current company, I had been having conversations with the Engineering team about how we would tackle a large, scale-related challenge deep in the bowels of the platform (not customer facing). The team had fully researched and had achieved some early success with an alternative technology that seemed applicable for this particular problem.

So, in this very same week, we had come to a point where I needed to make the call on whether to schedule the scale-related work for an upcoming release. And while the Engineering team was convinced the technology would ultimately solve our challenge, we were not jointly confident in our collective ability to proceed safely. Because of this uncertainty around technical feasibility, I swapped out the work from the release, postponing it for a later date after more research and experimentation could be done.

The impact

As I mentioned at the start, these types of decisions are commonplace in a Product Manager's average week: problem decomposition to help reveal customer value, user testing to help reveal usability concerns, and ongoing engineering R&D to help reveal feasibility limitations. Still, it never hurts to return to some of the core product principles to remind us all why we are here. And thank you Marty Cagan for all your contributions, and for inspiring me.  

Look for more reports from theProductPath around Product Feasibility, Usability, and Value 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

Create a shared space for departmental wish lists

In accepting a PM position with an organization that had no central place to capture and prioritize product-related requests generated from each department, I decided to pull together the lists from all the stakeholders into a common forum.

Of course departmental wish lists had been created over the years but were languishing as disparate spreadsheets, as bulleted lists in shared Google docs and as giant backlogs in our issue tracking software. These lists had not been kept current, were not being shared, and thus were impossible to synthesize for product planning.

What drove this decision

So what I really inherited was a bigger challenge and this was a known problem throughout the company. The lack of a central place to discuss product priorities had led to more than a few skirmishes and past product releases had been poorly received as various constituencies inevitably had begun to feel neglected or and complained that the Product Team simply misunderstood their needs.

I am now in charge of the Product Roadmap. As any Product Manager knows, this is a challenging assignment as it involves collecting, verifying, and prioritizing inputs from many stakeholders. To get started, I wanted to review any previous roadmaps and revisit the current backlog of requests from Sales, Customer Support, Operations, etc. The old roadmap was easy to locate but when I started asking around for the backlog, I was surprised to learn that there wasn’t one.

The decision: Introduce the team to Trello

I needed to (re-)create a forum where each department could list their own issues and make them visible to the other groups. It had to be conducive for collaboration and ultimately, allow stakeholders to collectively agree on the next set of priorities. But most of all, it had to be easy to use.

I decided we would begin planning high level product strategy using a shared Trello board. Trello is a flexible online tool that helps you organize lists and is very simple to use. 

• The free version would more than suffice for the size of our team and our limited needs
• Those who chose to invest more energy in capturing their requests would have ample means to do so using Description fields and other Trello features
• Each card would have its own comment thread to encourage and preserve group discussions 
• Users have the option to use card-level voting to avoid duplication and find common ground
• Plus, the good folks at Trello have made it work equally well in browsers, on tablets and on mobile phones

Plan of attack

I cannot share our company's product priorities here of course but you may adapt this approach for your company's own planning needs.

Build new board with a good name

I started by creating a new Trello board for our company and named it “Roadmap Priorities”. I chose the name intentionally as I knew I would need to push back on well-meaning folks who would get carried away creating cards that were important to them and the company, but ultimately unrelated to our product strategy. Instead, I encouraged them to create separate Trello boards for their own departments.

Create a list for the current release

To provide some perspective to the group, I created the first list on the board and backfilled it with cards that represented our current set of priorities, mostly to provide a model for what we would be aiming for in future strategy sessions. I made this the left-most list on the board so they would see it first and that proved helpful in on-boarding users who were new to Trello.

Prime the board with existing lists and examples

I created separate lists for each Department so that each would have a place to add their own set of cards. In an effort to prime the pump, I imported a few lists from existing spreadsheets that had been floating around some of the departments. For other groups, I created some sample cards to give them a starting point. In this way, I was able to accelerate the adoption of Trello and the roadmap planning discussions. 

Use colored labels for Each department

I used Trello’s colored Labels to assign a unique color to each department. This has made it easier to identify the originating department for each request and, as we move over cards to create a single “Release” list, has allowed us to see the relative priorities of each department. Even better, by combining multiple departmental labels on a single card, we were able to quickly find common ground among common requests. 

Invite collaborators to the board

I formally invited all the department heads to join the board. For some teams, it made sense to invite more than one person, especially where I anticipated some early, tool-related friction. Each collaborator received a friendly email invitation with a simple call to action to join the Trello board.

Onboard stakeholders

Even though Trello makes the sign-up process easy for new users, I expected and struggled with early engagement. As a precaution, I also schedule 15-minute meetings with each stakeholder to get them past the initial access challenge (e.g. logging in) and to provide a quick tour of Trello. The preparation (described above) went a long way to getting early buy-in. Stakeholders immediately identified with their department and were comforted to see familiar items in their own lists.

In explaining to the stakeholders how I would be using the board and the cards on each list, I also tried to motivate them by strongly implying that the best prepared departments would have a chance of seeing their priorities folded in to our roadmap.

The impact

The results for our company have been quite promising in these early weeks. Five of the six departments have been very active on our Roadmap Priorities board and that is making the planning for our next release much easier for the Product team. Trello deserves a great deal of the credit for providing such an amazing tool and we have witnessed its broader adoption throughout the company.

Look for more reports from theProductPath around Trello, roadmap planning, and working with stakeholders here on PM Decisions.

More articles from our blog PM Decisions