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
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.
In an attempt to summarize our collective accomplishments over the past 12 months, I decided to create a simple, 1-page chart that communicates the product advancements and highlights remaining product opportunities.
The Product Decision: Use the familiar customer process as a backdrop for reporting finer-grained enhancements across the entire product suite.