One of the traditional battles between PM and PD is how much to implement of a particular feature. The PD has designed the full functionality and s/he argues that if the team implements just some part of it, it won’t have enough quality nor solve all problems of the user. S/he also knows that if they don’t implement all, probably it won’t be done as other things will get prioritized. The PM is pressured to improve their KPIs and s/he argues that they can launch in different phases adding value to the user as soon as possible.
This scenario makes sense in feature factory teams which only care about releasing features. However, product teams shouldn’t care about releasing features (outputs), they must care about supporting company objectives (outcomes) while offering the best user experience. Sometimes they add features, other times they iterate or remove them or they focus on processes and the service the company provides.
This dichotomy has one central false assumption: If you do less, it means you are releasing with less quality. Some thoughts on that:
- The bigger the solution, the later we learn if that’s the correct approach. If we do a small solution or an experiment, we can learn much faster. With that information, we can invest more time in that direction or decide to change the approach. Optimize for learning!
- We should only design what we are going to deploy to production. If we do more, we are over designing. It’s good to experiment on low-level concepts, but we shouldn’t go farther than that without aligning the scope between PD-Tech-PM. Consider ‘design’ as the combined work of process+flows+ux+visual+tech design+data design.
- If we do user-testing with design prototypes, we have a certain degree of confidence that the solution could work. But until it’s released in production and we see the numbers, we won’t know the impact.
However, reducing the scope too much brings other problems:
- The change can be so small that it biases the experiment and we don’t learn. That’s why we need to agree on the Decide phase what the scope of the project is to achieve a meaningful outcome, and what we are going to measure.
- If we split the Decide+Design into small pieces done in different weeks with other projects in the middle, the PD may change context too often. The team needs to find a balance, especially when the direction of the solution isn’t clear. Usually, once we see our way of attacking the problem, the change of context is less damaging.
This dichotomy also seems to say that only the PD cares about quality and just the PM cares about releasing things. I would say this dichotomy would be real if the Product Designer were instead a pure UX/visual designer, and the Product Manager a Project Manager.
Last but not least, let’s remember that launching small solutions without understanding the problem isn’t going to reduce the time it takes us to find the solution. This thought on the dichotomy of quality vs. time to build is related to the way we decide and design the solutions once we have prioritized the right problems and understood them.
In the end, nothing is black or white. Teams need to talk a lot and agree which is the minimum scope that is going to help them learn and achieve sooner the company objectives. Remember, product teams shouldn’t care about outputs; they must care about outcomes.