One of the many skills of engineers bring to bear is the ability to step into a wholly new problem space and start contributing almost immediately. This skill can be often appear to be magical but I have noted in the past that this is about a deep understanding of how to break apart problems into their most fundamental component. Rebuilding these components into a new and novel solutions is the last and important step, but there is an interstitial step that requires a kind of comfort with ambiguity and a lack of structure.
In this post I am really inviting non-technical PMs and managers to be really comfortable structuring spaces for discussion even when ideas are technical, not well known and poorly defined. My hypothesis is that you can plan for, anticipate and excel in these nebulous moments even without a naturally technical background.
Using negative capability to find engineering solutions
John Keats was an English poet, who wrote in a letter to relatives on the topic of great thinkers who, by his estimation, were…
"…capable of being in uncertainties, mysteries, doubts, without and irritable reaching after fact and reason."
I like to think of this as a mechanism by which we can construct solutions and ideas without being concerned with all the details necessary to make it possible. It allows us to discuss highly technical frameworks, solutions and ideas without seeing one single line of code.
Negative capability does not spend time concerned about whether a correct answer might be available for the technology at your disposal. In fact, you may get to the end of the exercise and realize an appropriate answer might never reasonably exist. However being able to apply a bit structure to this kind of conversation allows you to wander through the maze of ideas without be incumbered or concerned with limitations.
Structuring the conversation
One of the engineering leads I work with was structuring a session for folks of varying technical backgrounds to contribute to, and I really liked his approach for inviting input. He broke it out as follows:-
- Scenario overview
- Available Technologies
- Implementation steps
Let me describe how that went here.
Scenario Overview
Describe the use cases that your customers are currently enduring and that you think you can ultimately solve and/or improve. This information will allow the entire group to be on the same page, by aligning on the type of the customers you might be targeting. This is the area where you might anticipate a Program Manager or Business Analyst to take the lead, however, when you are solving fundamentally technical problems for technical customers the entire engineering team might help flesh out the scenario.
Available Technologies
Create a list of the existing technologies that the team could bring to this problem and describe their strengths and inherent limitations. This feels like an engineering exercise and probably is, however, there is market and customer research that might help here also. Once again, there will be gaps in what we know and can do, however, you should move forward and assume the answer is potentially attainable and not stop the exercise.
Implementation Steps (engineering)
The final step contains the most ambiguity because it requires that you to connect the Scenario Overview to the Available Technologies in a new and unique way. This will be the first time you describe the service, product or app from end to end, preferably in a way that your customer will experience it. This will provide the entire group (engineers and PMs) with the first way to consider the answers in a tangible way, shared in the form of a doc or a mockup. This is the artifact that helps you align on a vision you want to validate with customers. Open it up to comments and edits early!
Comments are closed.