What I learned at DPS about building great products
Being a great Product Manager and building a product users love is not one of the easiest tasks. The job has so many facets that it is difficult, especially for starters, not to get lost in a sea of challenges. I was thrown in at the deep end myself and participated in the Digital Product School. A unique program to develop your product skills and at the same time work with well-known industry partners to create innovative products. After completing the program, I figured why not take some time to reflect on what I learned. The Internet is full of resources to learn about Product Management. But there were still a few things I learned that I was surprised about myself and probably wouldn’t have read anywhere else. Here they are:
To develop product & user sense, you need to balance a clear discovery approach with speed.
I always thought that without a clear overview of possible hypotheses and problems, it would be difficult to properly classify and interpret the results of user research. I felt that if you didn’t consistently build on previous findings, you could miss a lot. In the worst case, you could even steer the team in the wrong direction. Of course, a certain amount of structure and documentation is necessary to do good research. Looking back now, I’m surprised at how much it helped us to move quickly and conduct lots of interviews and tests, even if we couldn’t evaluate 100% of the interviews from the previous iteration. By going fast, we looked at many different angles and thus developed good user intuition. Even if not all results are summarized or an interview doesn’t always confirm the most pressing hypothesis, it gave us a good user understanding & empathy that we brought together in the end. Along the lines of if you ask a lot of questions, you’ll get a lot of insights and hence build a comprehensive intuition for your user and product. I had to learn to trust that the pieces of the puzzle will eventually fall into place, even if you don’t always see it right away.
Small experiments in many different forms paint a meaningful picture
I used to be a Data Analyst. Therefore, I knew about the importance of experiments and AB tests. It was always clear to me that qualitative hypotheses need to be validated by experiments. Research and developing user intuition are one side of the coin, but without validation against real user behavior, the coin doesn’t show the whole picture. I didn’t know you could do so many small experiments in a day, especially when you’re in the early stages of development. When you have a more mature product, it can get more complex, I can understand that, but I think a lot of people miss small opportunities to test and experiment. For example, we didn’t know what exactly our USP was and which USP appealed most to the users. To test this, we put signs in the elevator of the co-working office with a link that prompted a specific action. We changed those signs periodically with different wording to see what resonated well. I learned that even if you don’t reach the volume of users to get statistically reliable results, you can still learn a lot. In our case, it was more about collecting lots of different small data points that are not meaningful on their own, but in the context of a series of small experiments, they build up a picture.
The starting point is not always a problem
Honestly, this was the most difficult thing for me to learn. Because of my previous analytical experience and all the wisdom of so many successful people, the “problem — hypothesis — solution” schema was hard-wired into my brain. I read everywhere that you have to make sure you identify a relevant problem worth solving in order to build a great product. And of course, that’s still true. But sometimes the problem is just not that obvious or the starting point. In our case, we had a technology and had to go backwards to see where it could be used. We created an experience and tested it with users to see where it resonated with them and why. So we had a solution, a technology, and tried to find the problem it solved. It took me some time to get used to that approach. I think, especially with very innovative technologies, the problem they solve is not always so obvious, and you may have to develop the technology and test it with users to figure out what abstract problem it can be used for. I have to admit that this can easily lead to developing a product that is not really relevant to its users but I still think it’s a valid approach. It could be similar with virtual reality / metaverse — it’s hard to imagine how this could be helpful in someone’s life, but once you experience a good use case, you’ll realize the benefit.
Finding the sweet spot to give your team autonomy and ensure focus is hard
Good product teams are autonomous teams. And even within the team, the individual roles should have a high degree of decision-making freedom. I definitely find it useful to motivate people, get them excited about a vision, and show them how much they contribute — and let them contribute. That’s why I’ve always tried to let the engineers make the technical decisions and the designers make the UX/design decisions. As PM, I need to see the big picture and make sure we’re moving in the right direction overall. And that’s the fine line that needs to be walked: When is the right time to step in, how do you make sure you don’t lose focus and steer the team in the right direction without compromising the freedom of others. Sometimes you just have to do it. And that happens more often than I thought. The key for me is good communication and team harmony. I have found it useful to be very close to the team, especially in the early days when the team (not just PM and UX) needs to develop a feel for the product and the users.
The experience at DPS has taught me a lot about what it takes to build great products. There is a lot to learn and you will never stop learning. With the right mindset and even with little experience, I’m convinced that you just have to start this journey if you are interested in building products since there is a ton to learn along the way. If you’d like to connect and share thoughts on building great products, I’d love to hear from you on LinkedIn.
