Product Management for Agile Businesses: Development
When you’ve identified a problem to solve or an opportunity to address, how should you go about developing the best solution? What are the key things that you have to bear in mind?
Coming into the development phase of the Product Management lifecycle, you have a candidate that has been validated and prioritized. Hence it has become an initiative and will be in an ordered backlog with other initiatives. Given that it will soon be worked on, here are the key steps that can be expected to occur during the development phase.
Please note that this article will not go into the details of development methods such as Agile Scrum or Kanban; only touching lightly upon them where necessary.
Scoping
A scope document will need to be produced by the product manager. The principal goal of the scope document is to inform all parties from engineering to support to account management what is being developed and why. Hence it must not be overly technical, it is not a specifications document and should be kept relatively brief.
Coming into the process, this document will provide:
- a description of request that was made,
- the problem that needs to be solved or the opportunity that needs to be addressed, and
- the value that would be generated if a solution is found and implemented.
As the development phase continues, the scope document will also be updated with:
- a high level overview of the solution, and
- key metrics that will be followed to indicate that the initiative is a success.
Developing a Solution
Solutions will generally be developed with a cross-functional team that heavily includes engineering and probably some UX:UI in the software space. Depending upon the extent of the problem, it may be necessary to bring in more stakeholders, especially with problems that can be expected to have a solution that is tightly coupled to another group.
During solution development, there are really three main phases:
- Solution design and prototyping
- Development
- Testing
Solution Design and Design Sprints
For certain problems, the design sprint can be a great way to generate a solution. Without wanting to go into great detail here, the idea is to go from problem to prototype within a week in order to quickly generate and confirm a solution.
This works well for certain problems that are not overly complex, are large enough to merit the investment and will have good buy-in from stakeholders.
Solutions and Prototypes
Designing the solution is generally done in strong collaboration with engineering. Product’s role is not to come with a 100% baked idea, but starting from the value that needs to be generated, they should come with ideas that can be refined with engineering and UX.
It’s possible that multiple valid solutions are generated, and these can be tested during the prototype phase.
It’s worth bearing in mind the words of Sir Karl Popper when looking to find the best solution, and using this moment in the process to challenge and have challenged those solution we have proposed:
“The point is that whenever we propose a solution to a problem, we ought to try as hard as we can to overthrow our solution, rather than defend it.”
Prototyping
Why Prototype? Isn’t it a waste of time and resources? Prototyping allows us principally to manage risk. Building a solution that doesn’t meet the needs of customers is a huge and expensive waste. While prototypes never get to production and are thrown away, their value is based around increasing the probability that the initiative will be successful.
The amount invested in a prototype should therefore be relevant to the overall size of the initiative. There are different ways of creating prototypes:
- Mock-ups: perhaps the easiest and most common prototype are mock-ups of what the solution will look like. Using tools such as inVision, these can be made clickable to demonstrate application flow and make it seem more real.
- Videos: another generally low-cost prototype is the video that can demonstrate how a solution will work. This can be useful to show more complex end to end interactions.
- Coded Prototype: requiring more investment, but a good option where there is significant risk and/or there is a desire to have stakeholders actually work through a solution. A coded prototype is an application that is not production quality code, will not handle errors well, will use a set of test data and won’t generally require tests. It can be updated quickly with learnings from interactions with stakeholders.
As you can see, prototyping can go from cost effective to complete, depending upon the complexity of the initiative — in any case there is little reason for not going through this step.
Solution Build
With learnings from the prototype, the Product Manager can complete the creation of epics and stories that the engineering team will require to build out the solution. Within the initiative, which is often represented by one or more epics, it is important to correctly prioritize the different stories. If a significant risk or difficulty has been identified during the solution design, this should be prioritized early in the process to ensure it can be overcome and to prevent perceived delays later in the process.
As often as is possible, engineering should share their progress with product and demonstrate what they have accomplished. It’s important to identify any issues or devisions from scope and design as early as possible in the process.
From the product side, it’s also essential to be able to report back to the rest of the organization the progress that is being made on the initiative. This can be done simply by counting up progress through stories, but is often better to combine story count with an idea of the size to get to a percentage complete.
Non-Engineering Work
During the development phase, there is not just work to be done by engineering, there is also a lot of preparation that needs to be completed in collaboration with other teams. This is all part of the development process in order to be ready for the next phase.
- Support: what does support need to know to help customers with the new solution? Does any existing material need to be updated? Is there any new material that needs to be added?
- Sales: have they identified target customers that would be attracted by the new solution? What changes do they need to make to their sales process? What new questions need to be asked to customers during the discovery process? Is positioning worked out? What updates are required to sales collateral?
- Marketing: how will marketing promote the new feature? Are they working with sales to target the right businesses? Have they considered the standard updates to release notes and the business website?
- Account Management: which existing customers will be offered the new solution first? How will it be pitched to them?
- Legal: are there any changes that need to be made to terms and conditions or other impacts due to the solution?
Solution Testing
There are several different ways that the solution will need to be tested before it is really to be used by customers.
Most of the testing of the solution as defined should be done within the development team, either by a dedicated QA resource or by the developers. Development should not be handing-off code that is not functioning as expected.
In more complex cases, however, it is essential to perform more complex integration testing to make sure that all is working as expected and that the feature will scale to the size of the largest accounts.
Features with an important UX:UI change must be tested by the UX:UI designer before being considered complete. It’s important that the vision of the designer has been implemented correctly and that the delivery is cohesive and works. Often what works on “paper” needs tweaking when the final delivery is made. Moreover, it’s also important that the UX:UI professional can improve their skills through reviewing the implementation of what they have designed.
Tracking Development
Development phases can take a significant amount of time and will leave most stakeholders at a minimum curious about the progress or requiring to know when deliveries will be made in order to coordinate their work.
In most organizations, product leaders need to provide updates on a regular basis to executive or cross-functional committees. Tracking progress is across all initiatives and indeed candidates is not a simple affair, and reporting in a way that people understand is not obvious.
Using tools can help. In Product Roadmap for example, each candidate and initiative enables progress to be tracked across multiple steps and is then rolled-up into one percentage complete number.
