Developing software products is a messy process. It’s messy because it’s so flexible and fairly new, only about 60 years old. It’s also abstract and not limited by the physical world, only by our creativity.
If you’re building with more concrete mediums, whether it’s furniture or a cake, there are well-documented rules about how parts work together and how it should look. In this sense, software engineers more closely resemble artists such as writers or musicians where rules are flexible and the result isn’t how it looks, but how it makes us feel. Great technology delights - think of the raw excitement the first time Steve Jobs presented the iPhone in 2007. Or the sheer joy of finishing tedious paperwork in minutes instead of hours because a computer automated it.
But, building delightful products is a process littered with worries. Work experience can help because it closes the gap between the execution required and final product vision. Unfortunately, experience is a nice way of saying learning from mistakes and there are always new ways to make mistakes. Experience isn't always enough.
So, what are my worries?
In the beginning, it’s if I understand the actual problem. In development, it’s if the product will work as expected. In launch, it’s if customers care enough to use the product. In meetings, it’s if my peers respect my credibility enough to buy-in. In exec presentations, it’s who gets final say on the priority of features.
Even with all of this complexity, the art of building a software product can be described in a simple story. Listen to potential users telling you what they think they want. Interpret those wants to what they actually mean. Organize and prioritize those requirements with the development team. Release prototypes that users can touch to uncover unknowns. Evangelize the Product vision to executives and colleagues to enlist support. End of story.
Within each of those steps are pitfalls. What are they and what’s my approach? I see them as 3 parts: the vision, the execution, the buy-in. Each part requires combining opposing skills: storytelling and technical, logic and creativity, details and vision. A Product role relies on informal authority, which means flexing skills and communication style to match the situation in order to drive the process forward. Underpinning everything is a constant self-awareness of the political environment and a relentless drive to solve problems.
The Vision - figuring out what to build
In the beginning, everyone has a chaotic combination of ideas. Nothing is organized, in order, or linear. People may have a few high-level requirements but very quickly there's a need to figure out the details. It can be overwhelming.
It's a patient process of collecting requirements from discussions and industry research. Next, is synthesizing how the pieces fit together. It's as if you started a new puzzle - a few different pieces fit together but it’s a long way before the beautiful image on the box. Chipping away at the requirements is the same process - start by grouping puzzle sections by different criteria: edge pieces in one pile, blue pieces in another, and so on.
The pieces can be grouped into larger buckets called stories. Prioritization can be done at even this stage in the process, as each story is evaluated whether it's critical for launch. Stripping away non-critical pieces or duplicates means understanding the problem well enough to apply critical thinking, a true sign of progress.
Once Stories are set, building a visual flow diagram from the stories, known as Story Mapping, of how the product works and interacts with teams from start to finish is a great next step. This exercise is about being okay with being imperfect, since the final workflow will change as more information becomes available. The directions of arrows and boxes may change, but value comes from the exercise of creating the map because it forces a deeper understanding of the problem being solved.
In the end, I have the earliest versions of prototypes - a relatively clean summary of Stories & and a visual of how they all work together. These prototypes, without a single line of code, let me have valuable discussions with stakeholders and get feedback to start building support. Slowly, the goal is to make sure the conceptual picture of the product that they have in mind matches mine.
The Execution - a framework for prioritization
There are always more features requested than there are resources available when building a product. Developing a framework for prioritizing features is a tool that can be relied upon for consistent, quick decision-making. It’s a virtuous cycle that empowers the team - shipping features quickly builds credibility, provides recognition, and gives them confidence to tackle even bigger challenges. The hard part is just getting started.
Over the past few years, my Data Science education has inspired me to approach problem solving as a set of probabilities. In reviewing all feature requests, what is the likelihood that a feature will:
- work as expected
- have a large enough impact on the business
- be executed by our team effectively considering our skills, resources, & time
- adopted by the broader organization
- get buy-in from supporting teams & executives
- be derailed by known unknowns and unknown unknowns
Outcomes are roughly estimated for each feature and evaluated accordingly. This framework is also a cheat sheet to help prioritize time; after the easy wins, it may be worth sparing time investigating features with low probability of success but an outsize impact on the organization.
One way to help understand how probable a feature will be successful is through relentless testing and discovery. The number of tests, and consequently new discoveries, in a year has an upper bound since they often need a minimum of one to two weeks to see results. For every 5-10 tests, maybe 1 valuable insight is discovered that can move the needle.
Keeping a steady rotation of tests is similar to shipping features regularly - an organizational muscle that gets stronger with repetition. If shipping features creates an empowerment cycle, than continuous testing creates an innovation cycle within the team - a problem solving mindset, sparked curiosity, and better questions leading to breakthrough solutions.
Inevitably, momentum killers appear, such as a critical resource leaving the team, a high-profile client demanding a feature, or an exec's pet project taking away resources. Managing these challenges are a case-by-case basis that’s dependent on company culture, management, and politics. However, they all fall into the category of known unknowns and navigating product development through these distractions separates good from great Product Managers.
The Buy-In - align the organization
Influencing people required to move projects forward is the sales part of Product Management. As the product whisperer, it means reading the room and delivering a message that the audience wants to hear while still advancing your goals. It also requires understanding a person's motives so that their door to new ideas remains open long enough to get alignment.
Stakeholder alignment is a discovery-based process, similar to how I described product execution earlier. Building relationships across the organization allows informal discussion of ideas or concerns before any formal presentation. Incorporating stakeholder feedback earlier increases their ownership of ideas while managing expectations along the way.
Inevitably, resistant individuals appear. Identifying the reason for resistance relates back to motives - whether it's concerns about workload, in conflict with their performance goals, or a threat to their organizational power. Motives set the boundaries for the tone of conversations moving forward.
Discussion content should also be customized - are they a forest or tree person, visual or analytical? Speaker credibility is based on the ability to step into the audience's comfort zone - technical details with engineers, operational plans with support teams (e.g. legal, finance), and high-level summaries to executives. Speaking at the right level also develops empathy as the person listening feels you understand their concerns.
All of this continual discussion should pay off by the time a formal presentation and recommendation occurs. Roadblocks have been cleared and dissenting opinions have been neutralized. Congrats, you've aligned the organization to the Product Vision.
In summary, bringing a product to life is a long, arduous process. It's a battle of attrition where you just need to outlast every obstacle by using any tool at your disposal - creativity, logic, storytelling, analytics, patience, urgency. It's not meant for everyone, but it's an interesting, rewarding career for those that choose this path.
Image Source: User Story Mapping, Jeff Patton