P: Don't assume – test

Keywords:: PermanentNote

Reference:: R: Continuous Discovery Habits by Teresa Torres

Theory is great but unless it's put into practice it's closer to a fairy tale than it is to reality (P: Bring the metaphysical into the physical I need to create a better note about that).

This is especially true in product management because product teams tend to hesitate in showing their work. They're usually waiting until their new feature gets published. Once it's published, they realize how many things are wrong with their solution. This is because their assumptions regarding the initiative get validated after it's been completely shaped, and then it's already too late.

Why? Because they haven't validated if the solution actually makes sense to the business, creates value to the users, and is possible to be built in that way.

Therefore, as a product team, you need to validate your assumptions for an initiative as quickly as you can.

That said, there are three core types of assumptions you must test:

Business assumptions. Get stakeholders' approval early. We cannot ship anything unless it's inlined with the business vision and objectives. To prevent your work from being wasted, show it before you start serious design and development.

Value assumptions. Show your work ASAP. Create an artifact that encompasses the value of the solution as soon as you can and show it to REAL PEOPLE. Why? Externalizing your ideas into tangible artifacts tells us if our initiative can work in the real world. This means for example creating a simple wireframe to show a new feature, a one-question survey to determine interest, or drawing a story map to feature the user journey.

Technological assumptions. Include engineers early. As soon you choose the solution, you consult it with IT – even if it means a 5 min conversation. Such consultation is invaluable because engineers will point out a lot of BS, you're not aware of.

Relevant notes (PN: )/questions (Q:):