Get Started. It's Free
or sign up with your email address
Surprises by Mind Map: Surprises

1. We don't have usage data

1.1. We don't know how our clients actually use our products

1.1.1. We don't know if existing features are used or not We don't know if a bug impacts just 1 client or a lot

1.1.2. When implementing new things, we may implement something to take into account an existing feature whereas nobody uses it

1.1.3. we can't kill useless features

1.2. For new shipped features

1.2.1. We don't know if new features have been used

1.2.2. We don't know if new shipped feature have the impact we expect

1.3. Features in the roadmap are not enough data-driven

1.4. We can't demonstrate we produce value for existing clients

2. A lot of different versions are in production

2.1. Clients don't benefit fixes & features in latest versions

2.1.1. Why should client pay more?

2.2. It generates a lot of support

2.2.1. to reproduce the issue

2.2.2. to backport the fix on different branches

2.2.3. to test the branches

2.2.4. to release

2.3. Clients are at risk when they are missing security patches

3. R&D is organized in component teams and not in impact teams

3.1. Makes harder to implement features involving several components

3.1.1. It requires time consuming extra sync (meetings, project manager)

3.1.2. One team may put in jeopardize the others

3.1.3. High risk of bugs and delay when integrating code from different teams

3.2. Roadmap is drawn to busy teams instead of focusing on the most important impacts for clients

3.3. Encourage teams to feed their backlog by themselves (by fixing minor bugs, tackling technical debt or implementing fun features)

3.4. Teams are not encouraged to collaborate directly with clients

4. Vision should be stronger with some KPI to follow the progress

4.1. To have strong arguments against competitors

4.2. To focus on what is important for the roadmap instead of reacting clients' requests and "I think that..." syndrom

4.3. To measure the impact

4.4. To inspire, involve and give autonomy to teams

4.5. To design innovative solutions instead of copying competitors

5. Collboration with clients is weak

5.1. To better identify and qualify pains/problems

5.2. To validate ideas/assumptions

5.3. To involve users during the implementation process

5.4. To get qualitative feedback after features shipping

6. It's not clear what Product Management means for a lot of people in the org

7. Try & Learn Faster

7.1. We take too much time to deliver a MVP

7.1.1. We waste time to implement a full feature without being sure the actual value for clients

7.2. Shipping pace is too long to get live feedback and react on it