Reforge Product Strategy Program and Internal Tooling Community
I am taking part of a six-week product strategy course through Reforge. Many product management people that I talk to have little to know training. The training could come from Scrum product owner training. Or it could come from a business administration type of program. Often the people I meet in these roles represent someone knowledgable about their business with an opportunity to provide strategic impact. Since starting the reforge program it opened my eyes to the breadth and depth of this field. There are business models I’ve never heard of or considered.
Reforge Format & Feature Strategy
The Reforge content is slide based. There are videos yet it is a presenter talking over the slides and written below the content. It provides tools and frameworks you can apply immediately. Each week there is a two hour event with an executive in residence or two that walk through a case study and how a framework can be applied to that case study. What is interesting about the content is that it provides structure and mental models on how to approach features. The content is clear that adding and removing features are essential parts of product development. Reforge warns that net promoter score makes sense for an entire product but not specific features. You want to find parts of your existing product that can be improved or removed because it is reducing user satisfaction. After the first event I created a survey to send out to my users to gauge their general feedback. Reforge provides a Qualitative Feature Framework to consider multiple dimensions about a prospective feature. It helps you walk through how big of an audience, impact to users, and business impact the feature might result in. This connects to the TARS framework which stands for targeted, adopted, retention, and satisfied.
Applying Reforge Techniques
Let me give you an example of a recent feature release. DevLab is a whiteglove platform meant to ease the burden of developing. Its adoption has not been fast as I would like but the main reason boils down to offering essential features that developers expect to use in our internal environment. Eventing is one core feature that many teams rely on because they often have messages they want to send to other applications reliably. If I apply TARS to this problem I can state that we are targeting 100% of developers but realistically we only want 100% of the realistic eventing scenarios. I did not research how many applications use this but I would wage that 20% of applications use this kind of tool. I want all users to be aware they have access to this feature. It is possible that users adopt this for future products of theirs and it meets their needs or lacks advanced scenarios. We are not planning to offer niche scenarios as we want this feature to stay commoditized. In the future as more adoption occurs I can query pods in production with the event sidecar installed. I will need to identify what teams own those products and send out surveys to those teams to determine their satisfaction. Once I have that I can calculate the score of satisfied users percentage divided by targeted users percentage. Adventurous individuals might implement their own functionality in a clever way and that might require me to do deep dive research via different avenues.
With this information you can analyze your product based on its overall feature bundle against a couple of 2 x 2 matrices. One is types of features which encompass overperforming, project, core, and liabilities. Liabilities are the riskiest but offer the most value. Core and overperforming can be augmented to further expand your product. Project features are ones that either require more investment, replacement, or removal because they do not offer much strategic importance. The live event did not touch on new features much. The content is helpful and warns about sources of new ideas that lead one astray such as vocal users, unqualified users, solutions not problems, and overanalysis. One area to call out is that Reforge appears meant for products with existing demand and not finding product market fit.
Internal Products / Tooling Community
From the start of the program the cohort collaborated in Slack in various channels. I did not expect to meet many others working on internal tools. We found a good study group with people from Bloomberg, Shopify, HubSpot, and many other companies running different kinds of products. One member of our group seems to be a few steps ahead of where I am at. We are ranging around 120 developers aiming at 160. He serves about 200 developers and 30 contractors. I am lucky that my product has a focus on internal LAN usage and not public cloud which limits the amount of problems and issues to fix. In our recent study group we shared our thoughts on the content. I gave my run down of a couple feature I considered using the qualitative feature matrix. It was well received and there was a little awe that I already found a way to apply some of the techniques. A theme we all shared was measuring adoption of features and knowing what to work on. In an internal environment there might be challenges or lack of systems or access to finding data about what’s important to fix. Communicating laterally and to management what is worth doing and what is not. I am excited to continue meeting with this group and learn what is working for them and their internal audiences.
Conclusion
I am learning many things from my peers and hope that my experiences can help them with their own initiatives. We all face struggles with prioritizing features, communicating to our audiences, adoption, visibility of adoption, and managing expectations. I think the access to a broad cohort of people working in a similar space at different stages of a similar journey is what makes Reforge worth the time. The broader business focus and thoughts that this community talks about is over my head. I hope that I can better grasp it in the future. I could not imagine how broad and wide this community could be until I saw it first hand.