Success! Following loads of hard work, you’ve completed the first phase of your product development strategy – the project, charter, and budget for a new product (or changes to an existing product) have been approved. Now begins the fun, and more hard work.
How Do You Move Forward with the Product Development Plan?
At the start of most development projects, project sponsors have a product roadmap or list of product features they want implemented within a timeframe and budget. When diving into the details, the gaps between the higher-level descriptions, estimated effort, detailed tasks, and implementation begin to emerge.
Oftentimes, product features were identified with minimal input from technical subject matter experts, or there was minimal information and time available to formulate budgetary estimates. Other items, such as infrastructure, support, and training, may not have been adequately considered. As a result, one of the first objectives on a product development project is to collaborate with the business, product, and technical resources to determine the overall feasibility and plan for building the product while identifying considerations for sustainable product delivery. With a preliminary assessment and planning, a foundation of what is necessary will increase the likelihood of successful delivery within the project’s constraints.
What Are the Key Components of a Product Development Strategy?
Your product development strategy should include five components, and they should be addressed in the proper order, to maximize efficiency and facilitate the success of the project.
5 Key components of a product development strategy:
- Identify the best people to include in discussions
- Ask the right questions to inform the product’s development
- Evaluate deployment and support processes that will be required
- Assess whether product features can be delivered within project constraints
- Use information gathered to create an easy-to-understand picture of development required – your product development story map and descriptions
1. Include the Right People in Your Product Development Discussions
Whether the work is performed with an agile or waterfall development methodology, engaging key stakeholders to validate product features, feasibility, and high-level planning is a critical first step.
Consider the following when determining who to include in product development planning meetings:
- Who can best clarify the product feature definitions, value add, target audience, and priority? Can the product audience be included?
- Will product features impact other applications or workflows? Who can represent the dependent products?
- Who are the technical resources familiar with product architecture and associated codebase? Who can represent database, application architecture, user interface, and/or integrations that will potentially be impacted?
- Should security and/or data governance representatives be included?
- Should infrastructure and/or software procurement representatives be included? Consider whether infrastructure and/or software is already in place to support the product features, and whether development, test, and production instances are established.
- Are there other groups who require input into the product’s requirements (sales, legal, etc.)?
- Has the project team been established? It’s best to include the team (developers, scrum masters, business analysts, quality analysts) in discussions for first-hand involvement in the process.
2. Ask the Right Questions and Clarify What is Required
Once key stakeholders are identified, defining a next-level detail of the requested features helps shape a thorough plan for product development. In an agile world, the exercise is called Story Mapping to produce a Story Map. Regardless of methodology used, review the following to build a solid foundation for the product development framework.
It is important at this stage to steer discussions toward what is needed as opposed to the how. Keep in mind, though, that a general idea of the how may be helpful for a clearer understanding of product development needs.
- Agree on project goals and scope:
- What are the overall goals or strategic initiatives for the project?
- Clarify scope – what are the boundaries?
- Clarify product features:
- Find a common language and understanding to define the feature and ensure stakeholders have a unified vision for the end result.
- Does it relate to a goal or initiative? What problem does it solve? If the feature doesn’t support an overall c. organizational goal or add value, consider whether it should be removed or deferred.
- What’s the priority relative to goals and other features? The MoSCoW method (Must have, Could have, Will not have) is one example of a simple tool for initial prioritization.
- Who are the product users?
- Identify project dependencies:
- Is foundational work necessary prior to build out? Is the feature a building block for another feature?
- Are other products or applications impacted? Do dependent changes have to be made in parallel and delivered at the same time? What are the options, timing, and associated efforts?
- Is there technical debt to address during development? What’s the value if addressed now versus the implications if deferred?
3. Evaluate User Acceptance Testing (UAT), Deployment, and Support Processes
Good UAT, deployment, and support processes can reduce costs and improve product satisfaction. Understanding the current processes and assessing gaps allows appropriate planning to address them during the project, instead of as an afterthought.
Some key questions to ask when evaluating UAT, deployment, and support processes are:
- Is software change management established?
- Is an efficient product deployment process in place? Consider deployments to development, test, and production.
- Will product training or organization change management be needed? Are there established practices and user acceptance testing processes established?
- Is a help desk or customer support established?
- Are owners in place for routine business and technical operational support?
The objective is to identify additional work required to successfully support the product and plan accordingly.
4. Assess Product Features with Project Constraints
Companies often have a development timeline and budget, even if using an agile methodology for project management. Work with stakeholders during the assessment to determine if, at a high level, the product can be delivered within the project constraints. Depending on the project size and complexity, this could be a simple exercise or require additional brainstorming.
If the envisioned product appears to not be feasible and constraints are not negotiable, connect with stakeholders to determine what is feasible and still valuable.
- Is there a minimum viable product which delivers initial value? Then, how could it gradually improve?
- Can the approach or complexity of features be modified to reduce development required? For example, can some tasks be handled manually?
- What could be deferred?
5. Start the Story Map and Story Descriptions
Now the work of moving from those high-level goals, objectives, and product feature descriptions into detailed development tasks can begin. There are tools and methodologies available to guide this work.
What is a Story Map?
A story map is used in agile projects to communicate the overall product development path while eliminating the need to filter through spreadsheets. In general, a story map captures the customer journey or product features in a visual outline. It’s also useful for communicating the path forward with sponsors and leadership. This is a living document and should be modified as priorities shift over the life of the product.
An example of a story map is shown below for a mock performance evaluation system. Story maps should adapt to a project’s needs. The information in the following framework is a useful guide on what to include.
Historically, feature backlog and planning information was likely contained in a flat list within a project management tool or buried in large requirements documents and spreadsheets. Understanding overall product development required filtering these lists and documents time and again. In recent years, collaborative visualization tools and agile planning processes have made it easy to capture feature planning information in simple pictures.
For an agile project, the outcome of these stakeholder discussions are inputs to the story map foundation and story descriptions. These can be refined further as details are gathered during sprint execution.
How to Create a Product Story
Stories are concise feature descriptions told from the product user’s perspective. Used instead of requirement documents, stories define development work in agile projects and have two important parts: a description and acceptance criteria.
Descriptions are typically formatted as the user describing what is needed:. For example, “As a [type of user], I want [a goal] so that [a reason].” The acceptance criteria are equally important since they list requirements necessary for story completion.
Commonly, the creation of good stories is an iterative process with team members and stakeholders as part of sprint execution. The key is to define the story description early in the process to adequately document the individual story.
Flow to Success
Requirements and priorities may evolve over the lifespan of a project. The story map and associated supporting materials provide a foundation on which to start sprint execution as well as assess changes and adjust development plans to meet business needs. In following a flow similar to the above steps, you too will bridge the gap between high-level product features and the product development process.
