Surprises

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

1.1.1.1. 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 related 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 actually used (ROI?)

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.3.1. Decisions are "gut feeling" driven and thus there is a lack of alignment on them

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/longer 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. Teams are not encouraged to collaborate directly with clients

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

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

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

4.2. To measure the impact

4.3. To inspire, involve and give autonomy to teams

4.4. To design innovative solutions instead of copying competitors

4.5. To have strong arguments against competitors

5. Collboration with clients is weak

5.1. To better identify and qualify pains/problems

5.1.1. We often focus on solutions and/or competition instead of understanding real problems

5.2. To validate ideas/assumptions

5.3. To involve users during the implementation process

5.4. To get qualitative feedback after feature 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