As software product consultants, we’re typically not in a position to take responsibility for significant product management decisions. However, we care a lot about the decisions that are made and want to know that our customers have the best information and context to make their decisions.
At every stage in a project, from sale to delivery, we can provide important information to help frame product management decisions. Below are a few things that a good software consultant brings to the table when product management work needs to get done.
Software Industry Experience
Our customers know their markets deeply; we know software deeply and across a wide variety of markets and platforms. We have a deep repository of functional patterns and best practices that we apply to solve problems effectively and efficiently. We know what tools and patterns are pushing the leading edge of software; which ones have a longer expected useful lifetime; and how to weigh the risk, cost, and benefits to align with a product’s needs. We have data from building other products to provide context for early estimates of product scale.
Every product we build gets the benefit of our 15+ years of experience, whether we’re building a customer’s first software product or their hundredth.
Human-Centered Design Practices
Understanding users’ needs is critical for product management. Sometimes customers have good, up-to-date information about their users; sometimes they need some help gathering more information. We have experience conducting user interviews, experimenting with paper and digital prototypes, leading innovation games, and doing other human-focused research to help bring useful information together for the product team.
We’re also big fans of data. Analytics and analysis of other application data can help frame a decision with concrete context. For example, it’s great to know that a feature is used before investing more time to expand it.
Tools that help learn about customer needs can feed important data into the product management discussion.
Tools That Build Shared Context and Frame Conversations
It’s no secret that we’re big fans of sticky notes, Sharpies, and big sheets of butcher paper hung on a conference room wall. Having a big, visual tool a team can use to discuss a product’s features, project timeline, or flow of information can be extremely valuable. Digital tools can be equally effective in supporting a team. We know what works and apply the right tools to help guide conversations effectively.
A few examples include:
- Walking through the top rows of a product story map when the team needs to make decisions about what user needs a product is trying to meet
- Reviewing the lower rows of a product story map with a team to discuss how features meet specific user needs and prioritize them into different product releases
- Prioritizing a product backlog in Pivotal Tracker to show the real-time impact of changing priorities
- Drawing process diagrams on a whiteboard or in a slide deck to help everyone see the same picture
- Using project data visualizations to help demonstrate scale, risk, and complexity and illustrate the differences between options
Shared understanding that is built through an effectively framed conversation and preserved in living documents like a story map and a product backlog provide long-term value to the product management discussion.
Insights into Complexity and Risk
One of the responsibilities we take on as consultants is to help our customers understand the scale of their product development needs:
- Approximately how big is it?
- What parts are more or less complex?
- What risks should the team be paying attention to?
- How long is this going to take?
We draw on our experience and well-developed intuition to notice the technical complexity and risk that our customers may not recognize. For example, we know that preserving the original timezone on a timestamp can add a surprising amount of complexity to what looks like a simple feature. The same goes for providing a PDF download of what the user sees on the screen.
Our broad experience provides valuable insights into complexity and risk.
Process and Measurement
Over the past 15 years, we’ve honed our practices to provide a process that supports building a software product in a repeatable, measurable way. We follow Agile practices in that we:
- Schedule and perform work in sprints (typically one or two weeks)
- Hold a sprint retrospective and sprint planning meeting with our internal team each sprint
- Hold a regular sprint review meeting with our stakeholders to demo completed work
- Hold backlog grooming meetings with our stakeholders as needed to keep the definition of detailed, actionable work ahead of the team
- Estimate in points that represent complexity
- Measure progress each sprint and feed that data back into the planning process
Measurement is important and serves as a prompt for important product discussions as the project progresses. Things we often measure include:
- How much actionable work is defined in the backlog? We like to keep four to six weeks of “sprintable” work accessible to the team. Having less than that prompts backlog grooming work to more precisely define upcoming features and plans.
- How much complexity is the team able to work through and complete each sprint? Time and cost projections are updated as a result of real team results rather than remaining in the dark.
- How much total complexity is defined? We can see changes in expected complexity over time as the product team makes decisions about what features to build or not build.
Measurement drives action when timelines are important or decisions need to be made in order to avoid blocking the team’s development progress.
Leveraging the Experience of the Atomic Team
When you hire an Atomic software team, you’re getting the benefit of our experience. Involve us in your product management discussions to help build broad context around the decisions that need to be made.