7+1 reasons why I would do it again
Let me share the story of my latest Design Thinking experience with you. I admit it was not a perfect project, still I loved working on it. Looking back, I identified 7 mistakes I as a DT coach and we as a DT team made. And exactly these mistakes push me toward doing it again…
At the beginning of this year, my newly formed scrum team got the task to simplify the configuration UI in SAP Integrated Business Planning (IBP).
Customers of IBP start with configuring a flexible, multi-dimensional, specialized database describing various data, and their common denominator. Sounds complicated, right? Sure, it is, it is almost like programming. Even for a small group of highly specialized experts, it takes months and several iterations to set up the productive structure.
The inner structures and full flexibility comes from some of the smartest people I know from my SAP career. They started to work on this product for years as research team members, and finally the solution hit the market with many productive customers, and now multiple releases are available. Naturally, the product quickly became ultra-complex: comparing with other competitive products on the market, it is the most flexible solution, but on the other hand, it is the most difficult and time consuming one to set up. Just another typical SAP solution, right?
My team’s task was to simplify the configuration UI of IBP. This is the UI which is used the most frequently during the several-month-long set-up phase. The actual users are consultants, and the current UI is full of technical stuff. At the beginning, I knew little about this UI and the underlying technical details, but – already having some decent DT coaching experience – I was confident that we would be able to achieve nice results.
Mistake #1: We have highly underestimated the complexity and the size of our challenge.
The DT team consisted of 2 UX colleagues, an architect, a scrum master, a KM expert, one of my PO peers, and myself, as a PO for the topic. It was intentional that we were completely new to the topic, as our stakeholders wanted us to come up with a fresh, business-driven approach instead of the technical way.
Mistake #2: I was the DT coach and the responsible Product Owner in one person.
As it turned out later, it was extremely difficult for me to support, keep together and rely on the team as a coach, and take responsibility for the result as a “single wringable neck” at the same time.
The first iteration
We started the DT work with some minor preparations (some initial interviews).
The DT method was new to most of the team members, and the first feedback was positive. They liked what we were doing, how we were working, and they appreciated the dedicated time for such an interesting and challenging topic.
We started open and unconstrained, with the hope that there would be enough time to validate the ideas and go on. Interestingly, the result of the first prototype was already a nice concept similar to the one we develop these days.
Mistake #3: We interviewed consultants and internal colleagues only in this round.
We had good reasons to do so – simply because no customer end-users ever used the old, techy solution. But experts – mainly consultants – are special, so we got feedback like “I do not care about usability” which we could not consider, as our target persona was slightly different.
The second iteration
After the positive feelings from the first round, we entered the second, which quickly turned into desperation.
Mistake #4: I was not clear enough in setting up expectations to myself.
I knew that the DT method was not a magic weapon, and it couldn’t promise a solution to everything, but I have lost my precaution, and I wanted to achieve beautiful results. Combining it with my limited understanding of the topic complexity, sometimes I felt dissatisfaction regarding the progress.
Mistake #5: As I felt the time pressure growing, we did less and less warm-up games.
So the team (including myself) became more and more tired. That is not too effective. Warm-up games are there for a reason!
Mistake #6: Too much speaking.
As the topic was huge, and our business knowledge was limited, we were not able to move from theoretical level to practice, this leading to endless discussions. And those days it was very difficult to moderate the sessions.
I remember sitting on the floor, feeling lost and disappointed while the discussion went on about some relevant but minor details. I could not decide if it would bring us forward, just felt that everyone needs to have the same understanding, but the time was ticking, and there were no tangible results.
By the end of this iteration, we all experienced frustration. The results were somehow mediocre, and we had to face the fact that we wanted to achieve too much, which is not possible in the given timeframe.
Originally, we wanted to create a high level specification of the new Config UI. After multiple meetings with the stakeholders, we decided to continue with providing a concept of the new Config UI. What is the difference? Maybe not too much, and still, it was as great relief to us: from now on, we did not seek completeness, instead, we wanted to paint a consistent picture of a dream product without going into every details. And that really made a difference in our mindset!
The third iteration
Finally, we have found our way to the practical level: We picked an example, and the team started to fly. Suddenly, the spacious room started to feel tight, we ran out of drawing surfaces, we ran out of free spaces for our stickers, everything started connecting with things on the other side of the room, and all of us experienced the sensation of being creative.
Mistake #7: Time-keeping problems with finishing the prototypes.
For some reasons, I was not able to help my team to come up with meaningful prototypes within the original timeframe. In all iterations, we had to spend extra day(s) to construct them, and sometimes not everyone could be present. Too much things to do? Weak time-management skills from my side? Maybe both….
But in the end, the concept was there, and we got mostly positive feedback. This one, from a consultant, is indeed memorable: “If you implement it like this, there will be no need for me anymore”
What did we achieve?
- We have created and validated a consistent concept that will serve as a guiding star for the next few years. (Yes, it will take years to implement it J). In the past months, I was able to take the first module out of it, and we continued refining the details to get to the first development package for our next release.
- The team members got decent understanding of the concept, business and technology very quickly. Whenever I ask my UX colleagues to create a mockup, after 5 minutes of discussion we fully understand each other. In other projects, it can take hours, and a few extra iterations.
- Spending dedicated time to think about the product future and development implications, we helped the local management to shape the location strategy for Budapest.
- We have now contact to a bunch of consultants, partners and colleagues who we can turn to in case of questions.
So what are the 7 reasons why I would do it again? Well, learning from all the 7 mistakes, the result would be even better. And even with all those mistakes made, the project was a success!
+1: Those weeks with the DT workshops made me feel doing something worthy, and made us proud. We could feel the power of working in a team, focused, supporting each other. Despite all the difficulties, it was my favorite time from the last couple of years with SAP!
cool pictogramm to explain the whole story in one picture
Great blog! Thanks for sharing your learnings.
I think your team should show your concept to the consultants who said they "don't care about UI". I am pretty sure their reaction would be different this time around 😉 !
When I talk to many people outside SAP, they always wonder how can technical topics be taken through the DT approach. This is a good example and more than that spirit of experimentation is to be lauded about. This also reminds me of the BRFPlus and BOPF project that was taken in 2012 in SAP Labs India. Fortunately they did not have to go through the kind of experience that you went through. Good blog!
I really liked this blog. I've read a lot about the theory of DT, so it was good to read an - honest! - account of real-life experiences.
Can't wait to apply all I'm learning through SCN! Keep up the good work!