After collecting far too many stories about how customers had resorted to stitching together different parts of our product to solve the same problem, I decided to regroup with the extended product team to revisit how we might address the actual needs of our users.
I can measure the age of some of our primary product components in terms of years. This has positive and negative implications. On the plus side, I have a wealth of real-world application to draw upon as generations of users have been recording feedback with us about what is and isn't working (it is not uncommon for us to work with multiple Administrators at the same company due to turnover). All this input gives the team and I a wealth of information to sift through to find patterns of use.
On the other hand, I now also have both a significantly hardened code base that is more difficult to change and a larger user base that would be affected by any serious product revisions.
What drove this decision
I first started seeing the patterns emerge when I was embedded with the Sales Engineering team. Customers were asking for a way to start the same business process from two different points. We had built a tool specifically to accommodate the first case but unfortunately, to address the other starting point, we and ultimately our customers, were forced to reach for an alternative component.
Administrators found that configuring this second approach was harder but what's worse is that the resulting activity provided a completely dissimilar end user experience!
When I spoke with our Professional Services team who often assist new customers with their initial implementation, I confirmed that this was a common scenario and there was indeed pent up demand for a better solution.
The decision: Go back to the drawing (white-) board to review this prominent customer use case and find a more suitable way to solve this for our users.
I didn't feel like we needed to start with a blank page. After all, our customers had all found a way to make our software work and many of them had taken the exact same approach to get there. What was bothering me was that we hadn't given them an obvious solution path and more importantly, the end user experience was disjoint and reflected poorly on the product.
By gathering in one place the sharpest minds from each relevant department in our company, I would have an opportunity to apply some good, creative thinking to the problem. But leading a group discussion like this, especially with multi-disciplinary lineup would require some planning and coordination.
Plan of attack
I had been gathering details around this problem for months, and so I set about reviewing my notes to create some initial hypotheses. I poured through my notebooks, Jira stories, customer interviews, and related research to organize my thoughts.
In the end, I had some solid starting points for the discussion but stopped well short of outlining a final solution for fear of stifling the creative process.
Prep ahead of time to streamline the conversation
I had some presumptions for how I thought (hoped?) the brainstorming conversation would go. The day before, I stayed after work and put some initial thoughts on a big whiteboard. My intent was to use this as a backdrop for the dialogue.
In my experience, I have found that it is much easier to get people talking when they already have something to bounce ideas off of even if the starting material is somewhat inaccurate or incomplete.
Assemble a good quorum
I was genuinely interested in securing multiple points of view, but I also wanted to cover my bases so that the outcome could be vetted by all interested stakeholders. To that end, I invited participants from Engineering, UX, and Product as well as from Sales and Professional Services.
The latter was crucial for validating and clarifying the customers' challenges. The former ultimately helped me discover a product solution that was feasible and usable.
Have open-ended questions ready
Brainstorming often works better when there is some amount of prompting involved. I had already planned to facilitate but in a larger group, it can take actual prodding to make sure everyone's voice is heard. I prepared questions, some technical and others around usefulness, to provide sufficient opportunities to participate.
Even if I had already known the answers to the questions, I would still have incorporated them as collaboration tactics to get the ideas flowing and to promote a healthy discourse.
Stay on topic
Brainstorm sessions are expected to wander a bit which can actually encourage involvement and inspiration. But I had scheduled a short meeting so I also had to make sure I got what I needed from the group to be able to move forward. The trick was to limit the number and scope of conversation topics.
I started with a clear topic outline and stated what I needed the group to help me achieve. A few times I had to gently steer the discussion to get it back on track or to park issues that would have derailed us or sapped valuable minutes.
The impact
My meeting of the minds was ultimately a success. We confirmed several of the core hypotheses and as a result, I was able to proceed with my product planning. I was also pleased to have several new ideas enter the mix as well. In fact, there was one outcome in particular that I did not anticipate and that ultimately proved to simplify the resulting solution.
The approach I described here is a more formal approach to brainstorming, but it worked well given my constraints. With a bit more preparation up front and some lightweight oversight for the actual discussion, I was able to achieve positive results in a relatively short period of time.
Look for more reports from theProductPath around product strategy and product culture here on PM Decisions.
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.
The Product Decision: Use each and every opportunity to demonstrate solid product governance.