This post continues to examine the processes in place at Tasktop to support its software delivery apparatus. Part I reviewed the quarterly cadence that Tasktop follows to ensure coordination across the entire organization, while Part II explored the feature request template Tasktop follows to ensure that its customers’ and partners’ highest-value requests get satisfied in a timely manner. Part III discussed how the processes implemented within the product team enable them to successfully manage a growing suite of products and connectors.
This final installation looks at how our full feature development process has allowed us to incorporate the feedback of multiple stakeholders at the appropriate points in the design process, enabling Tasktop to build high-impact features.
Anyone in product management knows that much work remains to be done once a team has committed to building a new feature. There are many ways in which a feature or capability can be exposed in an application, and the extent of functionality a given feature can include is boundless. Given this, feature design and scoping are crucial components. Often times, however, the best design and scope of a feature are somewhat subjective—different people will have different needs, opinions, and preferences on just how the feature should be exposed, and what it should include. At Tasktop, we’ve found that the best way to overcome some of the inherent challenges of feature design and scoping is to define and implement a process that solicits input from the right stakeholders at the right times.
Here’s who is involved in the process, as well as its sequence.
- Product Owner—The product owner for a given feature is responsible for ensuring that it meets targeted use cases in an intuitive way with the appropriate level of technical sophistication and effort. She guides the feature through the right design and scoping steps, ensuring that the right people are consulted and, given her context and job of safeguarding the product vision and advocating for the customer, weighs in each step of the way. She also has a sense of what the story/feature backlog looks like for a product and is in a unique position to help decide what should be scoped in or out of a feature depending on any known future plans and on the backlog prioritization.
- UX Designer—The UX designer makes a given feature come to life. Working closely with the product owner, he uses his understanding of the user's needs and/or problems that a feature will address to devise a sensible workflow in the application. He creates low- to high-fidelity wireframes that evolve as feedback is solicited from the customer representative(s) and members of the development team.
- Customer Representative(s) — Though talking to customers directly is ideal, we also rely heavily on pre-sales and solution team members for feature design and scoping. They spend a lot of time with many customers, and hence have a good sense as to what needs are consistent across customers, rather than unique to only a few. They provide feedback on proposed feature designs and are very useful when trying to decide if a specific capability is truly needed for a given feature at a given time, or if parts can be added in later.
- Sr. Developer — The senior developer’s responsibility in the design and scoping process is two-fold: First, she helps identify any cross-team dependencies a feature might entail so that the teams involved can coordinate to deliver the needed capabilities. Second, she examines the design ideas provided by the product owner and UX designer and helps them understand the technical feasibility of each; she can also suggest/help brainstorm other alternatives.
- Full Development Team — This, of course, includes the development team that will implement the feature. When the design and scoping are far enough along, they participate by estimating the stories a feature has been broken into, and they collaborate with the product owner and UX designer during implementation as questions inevitably arise.
In order for the stakeholders above to provide the most impactful input, they must be consulted at the appropriate time(s) of the process. The following is an overview of the three broad phases our features follow, along with a list of the states that comprise it and a quick note on who is involved in that phase and why.
In this phase, we ensure that we understand the need or problem that a feature is meant to address, identify a high-level workflow for how and where the feature would be exposed in the product, understand any fundamental complexities inherent in the feature or associated with a given design path, and identify the parts of the application that would be affected so that we can arrange for coordination across teams if necessary.
The Specific States:
- Initial Assessment.
- Ready for UX.
- Initial TA.
Who’s Involved and Why?
- Product Owner: To drive the feature forward and ensure the problem/need motivating the feature is well understood by all involved, and to help guide the direction of the design.
- UX designer: To identify a few directions/shapes the feature might take.
- Customer Representative(s): To make sure the problem/need is well understood by the product owner.
- Senior Developer: To identify the components of the application that might be impacted by a given feature, and to comment on the potential design paths for a feature to voice whether any are particularly concerning or overly difficult from a technical perspective.
Refinement and Scoping
In this phase, we further refine the design and scope of a feature by deciding on a general direction and coming to an understanding of which parts of a given feature are essential (versus parts that are fine to be added later, or not at all).
The Specific States:
- Ready for Scoping with ENG/Pre-Sales and Solutions.
- Product Specification.
Who’s Involved and Why?
- Product Owner: To drive the feature forward and ensure that the right things are scoped in or out of a feature, and to ensure the design decided on is the right balance of usability and technical effort.
- UX designer: To further refine the details of the direction decided upon.
- Customer Representative(s): To weigh in on specific capabilities needed to meet the core user problem/need.
- Senior Developer: To help break the feature down into a proposed set of stories that the full development team will discuss and estimate, and lead the full-team estimation session.
- Full Development Team: To estimate the feature and make sure everyone has a solid enough understanding to begin story work.
In this phase, team members build the designed and scoped feature. They work out any remaining unknowns along the way, and demo stories to the team as they are finished to get rapid feedback, all before closing the feature and demoing it to all interested stakeholders at the end of the Sprint.
The Specific States:
Who’s Involved and Why?
- Product Owner: To answer questions about use cases, design, and scope that arise during the process. As with the full team, she also provides feedback on individual stories as they are demoed to see if there are small things that could be polished.
- UX Designer: To provide input into design questions that surface during the process and to ensure that new UI conforms to best practices and to the application’s style guide. As with the full team, he also provides feedback on individual stories as they are demoed to see if there are small things that could be polished.
- Customer Representative(s): To provide any input needed as questions arise during the development process.
- Senior Developer: To work on the stories that comprise a feature, help answer any questions that come up, especially if multiple teams are contributing, and to demo the feature upon completion.
- Full Development Team: To solicit input from the product owner and UX designer as needed, and to make the feature a reality in the product.
These specific states in these phases are fluid and provide a framework for feature design and scoping, since not every feature needs to go through the exact same workflow with the same roles involved each step of the way. Using this framework, we have improved the feedback process from key stakeholders at the right time, making feature development and delivery smoother on the whole.
- It’s important to determine the extent that stakeholder groups want to be involved in feature design and scoping. Some people/teams can be very hands off, while others like to feel more involved in the process. Knowing this will help guide you when you’re planning to consult various stakeholders during the process.
- While getting a sense for the above, erring on the side of reaching out more often (within reason) is generally a good idea, especially to start.
- Getting input on little things/details can do a lot to build trust across the different contributors/stakeholders.
- Make sure that the process involves getting at least some input from your customer representatives and from the development team in the earlier phases. If the former is consulted too late, the feature might end up missing the real customer need, and if the latter is consulted too late, you might need to go back to the drawing board if the design of the feature isn’t feasible.
- Understand that defining and implementing the process might take some time, so have patience. And realize that over time your process and approach will likely change.