Everyone claims that they are doing products in an agile, user oriented way. And yet, the majority of the products are still not welcomed by customers after being released.
There is a huge gap between what we think it means to be user oriented and actually been user oriented. In this talk I will present my personal methodology that I have developed during the last 9 years that helped me to build multiple highly successful products and services. The framework contains of the following pillars:
Identify the problem, problem should be:
* Real customer problem
*Problem that is top priority for the customer
Identify the solution:
* Is this the simplest solution for the problem?
* Is it easily integratable with the current customer infrastructure?
* Solves a problem that will exist (and will remain primary problem) by the time it is delivered
* Easily pluggable in the existing customer’s infrastructure
* Cost of adopting the product should be smaller (ideally: drastically lower) than the benefits that customer will get
Execute:
* Do not aim to deliver the solution, aim to onboard the customer
* It is much simpler to deliver solution for one customer and generalize later than to deliver generic solution that can be used by at least one customer
* The only criteria of success is onboarded customer
We will show in detail how to build a team that executes in accordance with these principles, just some examples of key fundamental things:
* Success of the product is everyone’s jobs
* Engineers who are working on the product directly responsible to onboard the customer onto what they are building
* Done-done-done is not when code is deployed to the production, it is when customer is using it
While these are very common things that all of the managers/PM claiming to be doing there are many hidden traps when leaders are trying to do this, just some of them:
* This process is about incremental changes, my product is revolutionary.
* We have this amazing tool/technology/solution, let’s find the problem that it can solve for our customers.
* I have validated the problem, therefore my solution is also validated.
* I put the word “user” in my goal and therefore now it is a user oriented goal.
* Different user audience for validating the problem and building the product for.
It is very simple to pitch a free product to the students and ask if they will be using it for free, it is a completely different thing to sell the same product for money to a CTO.
* Ignoring the last mile of integration. *Sticking to the original plan/scope while user’s problems clearly have changed
We will also discuss how to start transitioning an organization into this mode, how to start refactoring the engineering team and whole organization, what should be the concrete first steps, like:
* Do a revision of the roadmap:
* put a concrete problem next to the feature
* Re-evaluate problems
* Stack ranked problems (instead of feature)
* Refactor incentives for eng team to start onboarding customers (solving problems for the customers) instead of just delivering features.
Introduce processes of building deep connections with the customers and collecting/evaluating their problems.
12 июл 2024
