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

Create a reference application for our software platform

Image source: https://www.flickr.com/photos/kovah/15518650302

Looking to better promote our full-featured software platform to external developers, I decided we should lead by example.

After investing a great deal of energy in overhauling the publicly available programming interface to our cloud-based platform, our company was ready to release it to the masses. Our marketing team was developing a campaign to promote our revamped REST API but I felt that something was missing.    

What drove this decision

Our original, SOAP-based programming interface, while feature-rich, was considered outdated and had truly lost favor with external software developers. It was time to embrace the new RESTful paradigm and we knew that we had some work to do to reengage this audience.

So, in tandem with the launch of the new REST API itself, the company was erecting a developer-focused, community-style web site to include a full set of method-level documentation and source code examples. We also planned to highlight a few partners and customers that had invested in the new API and who had built their own integrations to our platform. 

But to really show off the power of this new API, to lead by example, we needed to do even more.

Image sources: https://www.flickr.com/photos/76886703@N00/6094026942, https://www.flickr.com/photos/sometoast/1405380577

The decision: Build our own API-based application as a reference model for the developer community

Several months before this decision, our Product team had started plans to deliver a lightweight, mobile-friendly application that would help our customers gain insight into the business processes that they were automating with our platform. However, we had not landed on the specific architecture we would use to build this new application.

This decision to create a reference app for the REST interface helped us connect a few important dots. We now had a path forward that would showcase the new API while also delivering value to our customer base. 

Plan of attack

To pull this off, we first had to put ourselves in the mindset of the external developer - which was a bit harder than we expected. We would build our new mobile application as if we were operating entirely from outside the organization. We would try to limit our use of any internal tools or frameworks to artificially accelerate development or to negotiate deployment shortcuts. Only after we went through what our target audience would experience would we truly appreciate the effort involved.

The details of our implementation, which covers everything from negotiating API keys, session authentication and runtime usage governors to UX library components, responsive design, and error handling are beyond the scope of this post. What is more interesting perhaps is that we decided to chronicle the entire experience and share it publicly on the developer community site.  

The impact

The greatest impact of this decision was a delay in getting our new mobile application to market. Choosing to go the full API route resulted in more time being spent configuring and troubleshooting the code for our mobile application - AND debugging the API itself.

There were up front costs and delays while we developed a parallel release environment and deployment schedule, separate from our primary code base; however, this ultimately helped us deliver iterations of the mobile application much more frequently as it could evolve independently without any direct dependencies on the underlying platform.

In the end, we would deliver our mobile application to happy customers who were completely unaware of our internal implementation decisions. But the payoff was magnified as we also delivered a complete application blueprint to external developers looking to embrace the platform. 

Look for more reports from theProductPath around product investments, go to market choices, and software platform promotion here on PM Decisions.

More articles from our blog PM Decisions