How we use the valuable-viable-usable-feasible product framework in Trucksters
A bit of context
This is a framework that was heavily recommended by Marty Cagan and Silicon Valley Product folks (https://www.svpg.com). I can’t say if it was originally invented by them or as they usually say, they just take good practices from every good product company. Now let’s go with our journey!
What didn’t work for us — the factory-like-product-team
I think this is the most usual way of building products, at least that’s what I got from conversations with developers, designers and PMs from different industries and levels of maturity, this way is widespread on the vast majority of product teams. And actually was how we made product back in the day.
In a factory-like product team, the PM decides what to do and translates an initial idea of what should be done, which is passed to the designer, who with the final designs passes it over in the form of a completed Jira card to an engineer.
Something like this
In my opinion, this way of working is greatly influenced by the consulting industry, where there are a few requirements coming from the client that are usually gathered by the PM (who, in my opinion, should be named project manager instead of product manager) and then passed to designer and engineers.
In these cases we suffered a lot of back and forth with requirements, misunderstandings and in the end, disordered feedback coming up and down the line that usually made everybody frustrated.
What was really bad in this workflow for us, in summary, was that the developer and designer usually did not have direct contact with the user or with the problem, that was PM work.
Neither designer nor the engineer were given a problem to solve, they were given directly a command of what to do. Can’t stress enough the subtlety, but at the same time, the huge importance of this.
This might work in a heads-down & produce environment such as most consulting firms, but in my opinion, is methodology poison in a product environment, as it eradicates one of the pillars for building a good product: Communication & feedback.
What did work for us — The Valuable, Viable, Usable, Feasible framework
In general terms, I think that a good product team is tightly bonded together, the engineer, product manager and product designer work together to find a solution to a business problem.
A good product team looks more like a round table where the whole team interacts and adds value to the conversation.
You can call this a tribe, a squad, a team… it’s not about the composition of the team, it’s about how they relate with each other, with the problem and with the stakeholders.
Each of the members of that round table brings something to the whole understanding of the problem.
The PM has to take care of the solution to be:
1. Viable: Is not only the solution going to be valuable for the final users, but it means that also the rest of the business is aligned with that. Something being viable i.e: means that our internal processes are adapted to that, that is compliant with the law, that it doesn’t represent a big risk in terms of business, or that is financially viable.
In general terms, it means that a given solution can be carried on and maintained from a business and more general perspective, rather than being valuable for the end user.
2. Valuable: The main role of the PM is to find that a solution is going to solve something and it’s going to cause the desired effects. Through a direct channel of communication with the relevant stakeholders (users, customers, business etc ), the PM has to be able to navigate and understand if something is worth doing.
The product designer has to take care of the solution to be:
3. Usable: The end solution might be valuable but there’s always a balance between something that brings value and the friction created to use it. Not only to overcome that friction but also to make the process even more desirable.
This has a lot of nuances, but in the end, the PD is responsible for something that is a nice experience in all aspects. This might imply correcting user flows, simplifying them, being able to spot pitfalls…
The engineer has to take care of the solution being:
4. Feasible: If we have a problem and we found a solution valuable and usable and viable, but there’s no human way of making it work… then we have nothing.
Not only that, but the engineer enriches the conversation probably with non-contemplated solutions that weren’t feasible not so long ago and provides a nice knowledge of cost.
Since she’s probably the best suited on the state of the art of feasibility if she understands properly the problem probably a long set of alternatives can be provided.
💡 Ideally this frontiers are as diffuse as posible, the really good conversations come when there’s a safe and open debate about this 4 main topics around a business problem. At that moment is usually when good product solutions are born.
Think of this whole process of open conversation as something live, it doesn’t have to be a specific meeting (though it can be forced that way) where the three main characters sit around a table with the business problem written on paper.
It can happen around a Jira card, around a Slack thread or in a room around a table.
You can think of this as a live process that happens along the way, where there is some harmonious and balanced back and forth feedback, and especially on companies that try to be as iterative as possible we have a constant feed of what is needed, what is working what is not… but those three characters are on the same loop, they’re in direct and constant contact and have the same context and the same vision of what’s the goal.
The Effects
I can’t solely attribute all improvements to this particular change, but among others had a great impact on how we produced for our users and I can confidently say that moving under this framework greatly contributed to:
- Reduce drastically our lead time from weeks to days
- Reduce a lot of the comms noise within the team
- Enter into a continuous delivery (cd) state-of-mind
- Increase the quality of the delivery on the first iteration
Do you want to play in a Product team like this? I have some good news:
In Trucksters we’re always on the hunt for good talent that we can make grow and that can make us grow.
If you want to know about our open positions just visit the following link👇
Even if you don’t find an open position that fits you, we want to know you and want you to know us👋
