Listen to the audio version of this article
Miscommunication between product development and technology teams is probably the biggest source of resource waste in software development. High-growth technology companies are facing increasing demands for product deliverables, and thus, proper planning is sometimes foregone. There are multiple signs that show a lack of product and tech team alignment:
- Products not delivered to the requirements.
- It’s taking longer than planned to deliver product features.
- The teams have very little interaction and communication on a weekly basis.
- The tech team has to “re-do” their infrastructure because of new product requests.
- The pace of development feels slow compared to the competition.
- The tech team often asks: “Why didn’t you tell us this before?”
Successful companies actively manage this interface between the two teams and have clear product and technology roadmaps which are understood by everyone. However, currently, there aren’t any popular methodologies that solve this problem in a structured way.
Instead, most of the time, these objectives are achieved in an ad-hoc way via unstructured meetings. The closest comparison to this is scaled Agile frameworks, but even these approaches are not always feasible for all companies, particularly smaller ones, as this approach requires the adoption of the entire framework.
One of the ways to easily achieve alignment between product and technology teams is to use the structured Technology Product Canvas
What Is the Technology Product Canvas?
The canvas concept has been around for many years. The key visionaries and innovators in this space include Alexander Osterwalder who created the Business Model Canvas, Roman Pichler and his Product Vision Canvas, and Jeff Patton, who is known for the User Story Mapping method and his Opportunity Canvas. I’ve used the canvas methodology to solve the problem of product and technology alignment and created the Technology Product Canvas.
The canvas will act as a quick way to facilitate team discussion and get everyone on the same page - literally. This is one of the most important benefits of creating this document. By going through the process, which can take as little as an hour, you will start managing that alignment between the product and technology teams.
The Technology Product Canvas forces your team to state and visualize the product roadmap goals, technology roadmap goals, and discuss each product-technology stage of the roadmap explicitly. This exercise ensures the teams are in-sync and everyone can leave the room with clear expectations and direction.
Through my work with tech companies, I have noticed that the intersection between business goals and technology capabilities is where the most risk lies. The Technology Product Canvas was created to manage this exact risk.
When to Use the Technology Product Canvas?
The Technology Product Canvas discussion is best initiated by the product owner when you have fully defined the product vision, conducted the story mapping process, and developed the initial product release roadmap. At this stage, it will be clear which product features are critical for each major release. At this point, the teams are ready to have a detailed technical discussion about how the product will be built.
The Technology Product Canvas exercise will bring clarity, sometimes conflict, but ultimately agreement about what technology architecture will need to be put in place to develop the product, and how the technology platforms will evolve to meet the needs of the product. It will allow the technology team to brainstorm different possibilities and ensure their input on innovation will be captured.
Let’s go through a more detailed example of how the Technology Product Canvas is used in a hypothetical new software venture so we can see it in action and learn how to use it.
How to Use the Technology Product Canvas
The Technology Product canvas is meant to be, primarily, a vehicle for creating focus, communication and team alignment. The canvas allows you to have a conversation with your technology team to figure out what technology architecture will be needed to support product development. Let’s use a hypothetical example of a new software product. A new location-based app to connect people with others around them - a community app to connect you with your neighbors.
Let’s say that you have been working with your startup team for a couple of months, you’ve got some great ideas and now you’re keen to plan out the software development. You’ve worked on your lean canvas, you’ve even created a story map of the process steps that a user will experience as they go through the app. Now you need to build it. So, you get everyone into a conference room, your product team and your technology teams, and you project a blank version of the Technology Product Canvas on the conference room screen. Where to start?
The first thing is to set expectations about why everyone is here and what you aim to achieve. Explain to your team that they are here to ensure a plan between the product goals and the technical tasks. Also, emphasize that you are not looking for perfection and that you will keep reviewing this every few months as you learn more and the requirements change. But, at least for today, this is a stake in the ground to ensure you are all on the same page.
Step 1: Define the Success Metrics
How are you going to measure if your overall plan is working? What are the business goals? They might be revenue in each release phase or the number of app downloads. If you are familiar with the lean canvas you might already have such numbers identified. Copy that information to this section. In this example I have used the following two Success Metrics: “Connect 1,000 people in our first year” and “Create our brand in Los Angeles”––one quantifiable and one qualitative metric.
But why do we focus on this first? It ensures that the whole team understands why we are in the room. We have a goal to achieve that is bigger than any product or technology issue. It is the business reason we are all here.
Step 2: Complete Your Product Vision and Product Release Sections
This enables the team to get clarity or be refreshed about what our product vision is and how we have currently defined our product development priorities. Write down the Product Vision statement and who the main target group is. Then, identify a few key product items that you are looking to deliver in each release. I recommend to fill-in these boxes as a team and not to have them pre-filled beforehand. It ensures that both the technology and product team members participate in the process of defining the goals. Work from left to right: identify the goals for the first product iteration – the big features that are needed to satisfy your customer needs.
In our app example, our Product Vision is “To enable real-time communication between people who live in my neighborhood in order to strengthen the community.” Following that, in the Product Releases, we might say that Version 1 is “To identify your current location, show who is nearby and communicate with their email address.” V2 might be “to show who is nearby and allow real-time chat.” V3 might be “to enable privacy and monetization.” These iterations of the product will be entered into the canvas as seen below. Keep the canvas as simple as possible so that people can see the big picture. The canvas is also meant to capture the long-term vision. Keep in mind that this might be the first time the technology team has seen such a clear picture of your product so spend enough time to ensure they understand each of the release and accompanying requirements.
Step 3: Match the Technology Vision to the Product Vision
Now it’s time to get input from the technology team and define their vision how the technology architecture will evolve. Start with the Technology Vision, a statement that outlines the big picture of development and which can survive vendor tool changes. In our app example, the Technology Vision might state: “To use the geo-location capabilities of devices that provide location information and to use serverless microservices to enable cloud collaboration capabilities.” We are not selecting a particular tool at this point. Think of the Technology Vision as the big idea for how technology will help here and what innovations we are looking to adopt that will enable a competitive advantage as well as a technology runway that can take us to our vision.
Step 4: Match the Technology Plans to the Product Goals
This is where the rubber hits the road. In Step 2, for each Product Release iteration, key features were identified. Now you need to define the Technology Plan for each of these releases. Identify what technology architecture and tools will be needed to support each of these functions. It is OK to identify exact tools and get technical. You can pivot in future releases if needed. The plan is to have the technology team to explicitly communicate what they will need to do.
Let the technology team lead this part and reassure them that the answers do not have to be perfect. If they need to go away and do more research, they can do that after the meeting. But the goal here is to complete the first iteration of the canvas, which can be updated later. Perfection is the enemy of success.
In our app example, we look at the product needs in the box Product Release 1. Based on these requirements, we might say that the Technology Plan 1 is “Develop a progressive web app using Ionic to enable the cross-platform app. Use device Geo-Location capabilities. Sync with Firebase back end. Use SendGrid email service.” The technology plan and goals described here should be just sufficient to achieve the product goals. Make sure the team is not over-engineering where product goals don’t exist.
In this step, we can finally see the power of the canvas–this is how we align the teams. We align the product goals with the technology plan. And that line in the middle? That’s the interface, which the product manager needs to actively manage between the teams.
Similarly, Technology Plan 2 would be “Implement user authentication using Facebook/Google authorization, implement real-time chat with Firebase database and Chat interface.” Technology Plan 3 would be “Implement Privacy/GPS hiding and in-app purchase methods for app upgrades.”
The process will require the technology team in your meeting to contribute to the discussion. You will have the opportunity for all the ideas and insights to be shared and discussed, and you will get team alignment and buy-in. This is where people on all sides of the teams will understand the needs, priorities, and issues that need to be discussed and where you will develop initial plans and agreements.
At this point, you have the first draft technology roadmap that matches the product roadmap. The key technology tasks are laid out in a visual flow that will help your teams know what to focus on and when.
Step 5: Identify Risks and Resources
Finally, once you have decided how you are going to build the product from a technology architecture perspective, it’s a good idea to discuss risks and resources. In our example, we might say for Risks: “There is a chance the progressive web app will not be fast enough.” If so, we could pivot to React or Native app development. For Resources, we are going to need people with skill sets in “Ionic, PWA, geolocation, and Firebase.”
Including these items here ensures that this one-page summary captures the salient elements that arise from the discussion and will be helpful later when you review the canvas again.
The Full Picture
Here is a completed example of the Technology Product Canvas based on our hypothetical app example above:
There should not be an expectation that the canvas has to be fully completed in the first go. You might disagree as a team as to what is a product feature compared to a technical capability and where to put what on the canvas. The purpose of the canvas is to initiate and frame a discussion so that at the end of the session you and the whole team have a much better conceptual agreement on how the development needs to proceed.
This document is now the core of your development plan. It is the high-level development roadmap and the technology team can now take this and frame its more detailed development tasks knowing the goals of the business.
Conclusion: Iterate Your Technology Product Canvas
The five steps in creating a Technology Product Canvas are:
- Define the Success Metrics
- Complete Your Product Vision and Product Release Sections
- Match the Technology Vision to the Product Vision
- Match the Technology Plans to the Product Goals
- Identify Risks and Resources
A very important benefit of the canvas is that it allows the teams to identify the ‘minimum’ technology that needs to be applied or developed at each stage. It helps the product team be aware of the technology effort required and any challenges that lie ahead. Product development is not slowed down by a lack of technical capability because the technical plans are synchronized and see enough steps ahead. In the app example, we would be getting our team trained or finding a SignalR technology expert as we get closer to releasing version 1 so that we are ready for release version 2 where that skill is needed.
You can download the Technology Product Canvas here. I recommend that teams conduct a review each quarter, and definitely as each release is accomplished. Feel free to modify the canvas to better suit your needs. I would be really interested to hear your feedback about how the Technology Product Canvas could be improved.
Understanding the basics
A product team can be a cross-functional team that is able to deliver a product increment. It would include a product manager, developers, etc. Alternatively, a product team can mean a group of people that deliver product requirements to the dev team like product managers, business analysts, data analysts, etc.
Product strategy defines what kind of product needs to be created for a defined market or user segment. Moreover, the strategy should define how this product will be brought to market.
Product strategy is created by conducting extensive market research that reveals user needs. This can be done via data analysis, quantitative analysis, developing MVPs, or other tests.
A technology team is a group of people with technical skills that are required to achieve some business goal like to develop a product.