So you asked, we'll deliver. Luke Hohmann (http://innovationgames.com) CEO provides a video in the context of sales support allocation process. Whether you are an agile team, marketing team, a scrum product owner, functional manager, brand manager, or a stakeholder in the product development process, this is for you.
Buy A Feature In the following video we explore the sales acquisition process and how a sales account manager gains insights from the team, feedback for the customer, and an understanding of multiple perspectives. Using this video as the example, I want to translate some of the value a product owner would glean from this type of engagement while understanding the stakeholder prioritization and the impacts from the team perspective in a virtual market game. I will cover these in Alternative Contexts I & II.
You may begin to see similarities with your environment as developers and stakeholders are separated in the early phases of project & portfolio management and resource allocation constraints depending on your type of organization. (Time Code: 1:00)
Alternative Context I: Program Managers, Brand Managers, and PMO
Using this type of interface from a program management perspective allows for a deeper understanding in what the customer (stakeholders) would pay for and opening a door for understanding why the priorities are what they are. Bridging the gaps in the big picture for the team enables the company to get behind the strategic initiatives using a system designed for feedback without the complex overhead of distributed team meetings and weak agendas.
- Emily: Program Managers
- Engineers: Stakeholders
- Objective: To prioritize projects projects using a virtual market for international and distributed teams by acquiring real-time in put from cross-functional stakeholders.
- Alternative approaches: Instead of using historical project costs or high level initiation budgets, Emily could price the projects too expensive or any one stakeholder to implement the vote requiring the functions to collaborate and negotiate on which project are the highest priority and therefore getting additional commitment to the budget necessary to execute successfully.
- Initial Insights
- Initial willingness to support a project without negotiation
- Likelihood of resource support and allocation in weaker matrix environments
- A clearer understanding of what's important to whom and a conversation describing how it came about
- Direct observation of the conversations that led to the prioritization
Alternative Context II: Product Managers, Marketing Managers, and Scrum Teams
Using this type of interface from a project perspective, whether agile or not, the team gains the insights directly from the stakeholders, but this time, let's assume the features were sourced from a customer/end user engagement that created a diverse group of features (i.e. Product Box, Prune the Product Tree, or Buy 'Em a Hot Tub) that may or may not make it into the release plan. In most organizations we've seen there are disconnects between the product ownership (the business) and the development team working to understand the requirements. This process of Buy A Feature allows the team and the stakeholders to interact visually and collaboratively, even with distributed, offshore, and international team members or stakeholders.
- Emily: Product Manager or Project Manager
- Engineers: Stakeholders and Development Team Members
- Objective: To prioritize features within a single product backlog or project documentation and obtaining buy-in and understanding of "what" the team will work on first
- Alternative approaches: Emily could include the perceived value of features or the perceived complexity (cost) of the features to be implemented. While this may not be available this early in the process, iterative planning may allow for a window of opportunity for this technique is major risk occurs with market deviation or unknown organizational impacts occur)
- Conflict Arrest: A clear understanding of what the team will work on from the stakeholders perspective
- Technical Debt and Risk Mitigation as Developers provide initial input to the feasibility and capability of the organization to implement more complex features before they are anticipated and expected by the business
- Immediate feedback and commitment by the business to customer of upcoming features
- Uniform Cross-Functional Product Vision
- Stakeholders and testers bought into a product are generally more available to speed up acceptance testing and ensure quality implementations to production