When I was studying at Carnegie Mellon for my master’s degree, I was majoring in Educational Technology and we studied instructional design and curriculum design. It is now, a couple of years after graduation and into my career as a product manager, that I realize that the concepts in curriculum design can be transferred (it’s a learning concept!) to product management.
A commonly used design process in curriculum design is backward design. I realized that the principles from this design process — thinking backward can help product managers build better products. In this article, I’ll briefly introduce the concepts of backward design and how this way of thinking might help you as a product manager to build better user-centered products with your team.
What is Backward Design
The concept of Backward Design is coined by Grant Wiggins and Jay McTighe in their book Understanding by Design [1]. It’s designed to provide a framework for instructional designers to design courses and lessons.
This framework is proposed to change the traditional forward design process that teachers often use: they consider the learning activities and assessments first and then try to match them with the learning goals. In backward design, the curriculum design process starts backward from the learning goals and then to assessments and instructional activities.
This model is sometimes extended to a five-step process: understand students in context, target explicit learning goals, focus assessments on progress, design instructions to reach goals, and plan evaluation for impact.
Wiggins and McTighe suggest that backward design is focused on the students and their learning. By explicitly identifying the learning goals, it can help teachers put more intentionality in designing learning activities and assessments that can truly help students reach that goal. Another benefit is that this model can provide transparency in instructions because everyone is clear on which learning goals they’re going for.
Thinking Backwards for Product Managers
You might be wondering — how does this backward design process relate to product management? The design of a curriculum and the design of a product are quite similar. The curriculum is like the product; the learning activities are the features in the product; the learners are like the product users. The benefits of backward design can also translate to product management.
In product management, a common mistake for some product managers (and for myself when I just got started) is that they focus too much on shipping features, instead of valuable products [2]. This is indeed the problem that many teachers have — they focus too much on designing the learning/teaching activities instead of on the students’ learning outcomes. The reason behind these problems is the same: they don’t have a clear, explicit goal in mind to guide their design. The backward thinking in the backward design process can solve this problem. It helps you find the real focus — user value and/or business value.
It can also provide transparency in the team and keep every member motivated with an aligned goal. When designers and engineers don’t know the goal or the value of the feature, they will not produce outstanding work as they don’t know what exactly they’re designing/building for. But if the end user/business goal is explicitly stated and agreed upon, every team member will have a clear sense of direction and will direct all their efforts on reaching that goal.
Thinking backward helps you and your product team focus on the real value and collaborate to bring it to life.
Translating Backward Design To Product Management
Let me try to translate the backward design process for product management. The five-step process can be: understanding users in context, targeting explicit goals, focus assessments on reaching the goal, designing valuable features, and evaluating the outcome.
Understanding Users In Context
The first step is understanding users in context. User-/customer-centric product managers need to do this step before they even attempt to move on to defining the problems or designing the features.
The main questions the product manager needs to answer are: Who are the users? This would include their demographic profile, their related work/life experience, their tech-savviness, their culture, their preferences, etc. What are their pain points/needs? This must include the context. When would they have these pain points/needs? Why would it come up? How do they currently try to solve this problem?
A user-centric product manager needs to answer all these questions without much hesitation. If s/he doesn’t even understand their users well, they won’t be able to solve the pressing problems for their users.
Target Explicit Goals
After understanding the users in context, the next step would be to pick a goal to target and make it clear and explicit. Users may have dozens of different pain points/needs and your business may have different goals at different times. As a product manager, you need to be clear on which specific user problem you’re trying to solve (this time) and which business goals are you trying to reach.
With a clear and explicit goal, you and your team will have a clear sense of direction. You will have much smoother communications as nobody needs to guess what others are trying to achieve. It can also prevent you from going astray, wasting precious time on solving low priority problems (Note: if you need help for prioritization, check out Ruthless prioritization for product people.)
Focus Assessments on Reaching The Goal
Once you define the goals, you need to determine how you’re going to assess if you’re reaching the goal or not. The assessments should be based on objective and quantifiable measurements. In the product world, you usually have product/business metrics, qualitative feedback, and quantitative feedback at your disposal. Some commonly used methods to obtain these measurements include A/B testing, user interviews, usability tests, surveys, NPS scores, ratings, etc.
It’s important to note that these assessments should be aligned with your goals. For example, if you’re focused on a user experience issue, you should probably look more at the user behavior metrics, usability tests, task success rates, etc. instead of on more lagging metrics like pay rates or LTV.
To help you pick the right assessments, you should ask yourself the following questions: Which product/business metrics are you trying to move? How are they related to the user/business goal? How much do you expect the metrics to move? How are you going to measure them?
Design Solution to Reach the Goals
When you’re clear on your goals and assessments, it is now time to design the solution to reach the goals. If you did the previous steps, you’ll find that you can have much smoother communications with your team.
You can now co-create the solution with your designers, engineers, users, and other stakeholders. Since you all know what problem you’re trying to solve and how you’re going to measure success, you will collaborate better and focus on building the solutions that can reach the goals. It can also help you prioritize the solutions that have better chances of meeting the users’ needs. In this way, you can avoid designing and building features that won’t contribute to the success of your product.
Evaluation of Outcome
All the previous steps are done before you ship your solutions, but you shouldn’t forget the last step after you ship it — you need to check back and evaluate the outcome. Sometimes, product managers are focused on the future and forget about the features already shipped. However, it’s important to keep track of your product metrics after shipping and summarize your learnings for the future.
This step wouldn’t take too long if you are clear on the goals, metrics, and assessment metrics. You can check if the actual outcome matches your assumptions and if it validates any hypotheses during your design process.
Summing It Up
It’s interesting to think about how concepts and ways of thinking may translate between fields. Thinking backward can help not only with curriculum design but also with product management.
By thinking backward, you can stay focused on the real important goal and align your team members on the same goal to deliver the true value to your customers.
Side Note: Amazon also recommends a product development approach called “The Amazon working backwards method”. It is similar to what I’ve described above in the way that you start with the end goal in mind, but it has different steps and is more focused on product viability and being customer-centric. If you’re interested you can find a link to more detailed descriptions in the references list [3] [4].
References
[1] Wiggins, Grant, Grant P. Wiggins, and Jay McTighe. Understanding by design. Ascd, 2005.
[2] Cagan, Marty. “Product vs. Feature Teams.” Silicon Valley Product Group, 18 Sept. 2019.
[3] Amazon. Working Backwards Booklet.
[4] “Working Backwards (the Amazon Method).” ProductPlan, 30 Dec.
Originally published on medium
