After we have ensured that we build the right things, it’s time to build the things right.
Create a detailed plan on what to build and when. Then, develop accordingly.
Thoroughly examine and break down every feature into small tasks, especially all technical tasks involved, leaving no detail unnoticed.
Identify and manage dependencies, specifically for larger teams working on a more complex product.
Run Agile Sprints, cycles or similar with empowered teams, providing timely feedback, ideally before the end of the current Sprint.
Implement continuous delivery to avoid tech debt piling up during longer implementation projects
Consider development holistically, including quality assurance, performance, documentation
Maintain and foster ongoing communication with all the parties involved in the delivery phase, especially the Engineering Team, UX Design, and customers.
Implement Continuous Discovery to foster learning and improve customer understanding
The feature(s) are available in a dedicated environment, ideally via continuous delivery.
The Product Management team agrees to the feature scope delivered with a solution.
The UX Design team agrees to user flow and visual design as built.
Non-functional requirements are met, most notably around quality and performance.
Engineering teams are in the lead and accountable.
Product Managers closely follow. They provide insights, answer questions, and help to prioritize – but they do not run the engineering team.
UX Design is actively involved in fine-tuning the user experience.
Agile Frameworks, like Scrum or Kanban to iterate quickly
Alternatively, software development frameworks, such as Shape Up to optimize the value delivered to customers
Risk management tools, e.g. to ensure that the highest risks are tackled first. Note the concept of Work as a Hill in Shape Up
Concierge Tests or Wizard of Oz implementations as ways to test MVPs to provide value to customers as quickly as possible, even though with yet non-scalable solutions
Avoid waterfall. Avoid Product & UX designing a solution during previous phases and throwing it over the fence to the Engineering team. While the degree of involvement of team members varies across the various stages, it is still a team effort.
Be open to change. Even after a solution has been agreed upon, new insights may occur anytime, suggesting scope changes.
Leave technology decisions to the Engineering team. Constraints concerning third-party technology, for example, might exist. However, neither stakeholders nor product managers can decide on the software stack.
Provide transparency about status. Regarding estimations, recall the GPS metaphor: Always know where you are and be transparent about it.
Quality is non-negotiable.
Avoid sandboxes. It’s nice when “it works on my machine” for one Software Engineer. However, that usually does not predict real-life behavior in a productive environment. Instead, use dedicated integration environments and continuous delivery processes.
Test small iterations. In B2C, most people are aware of A/B testing. In B2B, we found such tools less helpful because enterprise customers don’t want to act as guinea pigs. Instead, feature flags and similar methods can be used to provide early access to selected customers.
A B2B software company was in the process of finalizing a new feature that enables customers to sign documents digitally. A couple of sprints in, the feature had already taken form. However, some UI elements were missing, and predictable edge cases weren’t fully covered. But a standard end-to-end user journey could already be demonstrated in the software.
The Product Manager showed the feature during Customer Advisory Board meetings and user interviews. The engineering team received valuable positive and constructive feedback, which was passed on. After a quick importance and satisfaction assessment, a few quick-fix tickets were created and will be tackled in the upcoming sprints.
To continue the momentum, the Product Manager collaborated with a few Consulting and Presales colleagues, who had requested this feature in the past, to show the functionality to a manageable number of customers and prospects. The message was clear internally and externally: This is an exclusive sneak preview of a feature work-in-progress. Soon, more feedback flew in, and the Product Manager continued to work with the Engineering team to adapt the delivery.
In addition, a feature flag was added to control and easily manage who can see the feature on a customer-by-customer basis. At the end of the delivery phase, when the desired functionalities were finished, Sales and Consulting colleagues could further enable its visibility to a controlled group of customers by using the feature flag.
By the time the feature was released, feedback from nearly 10 customers had already been implemented.