When talented people with different backgrounds and professions work together on complex problems, fantastic products are created that our users love! 🥰
Our teams will solve real problems within a clear strategic context - not getting lists of functionality that needs to be made or roadmaps that must be delivered. Most importantly, the team themselves are empowered to decide what is the best way to solve a specific problem 🤝
At the heart of these teams, we find what we like to call “the holy triad”, with corresponding responsibilities and specific competencies.
📕 Product Managers (PM) are responsible for making sure the solution is valuable for the users while also creating long-term value for the company.
📙 UX-Designers are responsible for making sure the solution is inclusive, user-friendly and efficient for the users.
📘 The Architects must confirm that the solution is technically viable. Together with the team they will work on the problem and address the different risks as early as possible.
🤔 Does that mean that only these three get to have all the fun around Product Discovery? NO!
We want the entire team to be involved in the product discovery work. This way everyone gets ownership of the solution, making us ‣. The team must use different tools, frameworks and strategies to explore various opportunities and procedures before agreeing on a solution.
We trust the decisions made by the teams because we know they are best equipped in making those decisions. 🚀
We are tired of guessing and taking all the risks late in the process, never actually knowing if the proposed solution will actually work down the line.
There are two concepts we want to focus on to make this a reality.
Design-driven development uses design as part of a process to learn and better define requirements in order to build better, more informed technology solutions.
This means that when the team come across a problem, they brainstorm different ways of solving the problem. To learn which solution works best for the user, the team iterate fast together with our users. Using prototypes or other strategies to learn more with every cycle.
Eventually, the team knows enough to decide what path to take. So then you start to code? No, not yet. Now you take your time to thoroughly design the feature with continued customer feedback. This also helps the team flesh out technical requirements along the way all while defining a real scope of work prior to coding.
This is all nice and dandy when it comes to things we haven't built, but what about after? Once the solution is finally done and used by our customers, how do we know if it had the desired outcome for our users?
We need to know how the solution is used. When do they use it? How long does it take to use it?
The list goes on - we need more data!
Proactive and effective measures…