What I learned at Digital Product School
Mar 6, 2020
During September, October, and November of 2019, I was the AI Engineer of Batch #8: Team Phoenix of Digital Product School. It was an enlightening and memorable experience. The lessons I learned are worth sharing. Here I will share some of the learnings related to product development and working in a cross functional team. But before diving in, let me first tell you about what Digital Product School is all about.
What is Digital Product School?
Digital Product School (DPS) is a three month training program by UnternehmerTUM where people from different backgrounds and nationalities come together and work in teams of 4-6 people. Each of the teams consists of the following roles: Product Manager, Interaction Designer, Software Engineer, and Artificial Intelligence Engineer. Each of the teams are provided with a problem space from various industry partners. The teams then explore the problem space and develop a digital product to solve real world problems. This whole journey is guided by the core team of Digital Product School to ensure that the teams learn the right approach towards developing a product that solves the targeted problem.
Product Development
The core concept is to conduct user centric development. All the learnings are based around that.
User centric product development is key. Everything revolves around prioritizing user needs. In the end, they are the ones who are going to decide whether the product is worth their time/money or not.
Conduct a lot of user interviews. You have to know what the users’ pain points are. How else are you going to solve their problems? Go out and talk to users. It is also important for the engineers to be involved in this step in order to empathize with the users. Don’t ask what problems they face because it is highly likely that they might say they don’t face any problems because the question bears different meaning to different people. Just talk and try to understand which part of their experience of doing something annoys them.
Observe users. In my opinion, this is more important than asking users a bunch of questions. Because what a user does, says a lot more than what the a user says. Let them show how they go through a process. This gives you a lot more information to make a wise decision. For example, initially we set out to understand users’ problems when they try to buy public transport ticket. However, what we found out is that they struggle more with trying to find out which ticket to buy. So don’t bound yourself by any preconceived notion.
Don’t fall in love with your solution. Constantly validate all the assumptions you make. Your ideas and hypotheses might fail miserably when taken out to the users and tested in real world. Be prepared to change the solution and adapt as you gain more understanding of what the users need.
Fail fast. It is obviously better to know that your idea is not going to work before you invest a lot of time and man hour into developing the product. Paper prototype is your friend. Validate ideas before investing in them.
Keep testing and iterating. While you develop the product, keep going out to the users and test every iteration. When you work obsessively on a product, it is very easy to overlook obvious quarks in the product which become apparent when someone with zero knowledge about the product uses it. Also, testing allows you to get a better understanding of how the users are using the product. Observe their behavior, and adjust the product accordingly.
Ask a lot of why. Users typically don’t know what can solve their problem. At one workshop, we were presented with the following example which I really liked. It goes like this: When people used to ride horse carts, if you would’ve asked them what change they want, they would’ve answered that they wanted faster horses. It is only through asking why they want that, you get to understand that they actually want to reach their destination faster.
Working in a cross functional team
Make tasks visible to the whole team. Put all the tasks on a digital or physical board. This ensures clarity in the team and reduces confusion about who is doing what.
Break down tasks to the smallest pieces. This is especially important for engineers when they are working with people from other functional areas. Why? Because the team mates might not have the understanding that a task like “build login” is actually a bunch of tasks like “build login page”, “build login backend API”, “test login”, “deploy feature”, etc. Breaking tasks into their smallest forms allows everybody to have a more realistic expectation.
Be very specific when defining tasks. Using abstract terms when defining tasks might create different understanding if different members of the team. Since everybody comes from a different background, words can convey different meanings to them. The more specific you are at defining a task, the less confusion it creates.
Resolve conflicts smartly. Sometimes use a democratic process. Other times it might be more important to prioritize the opinions of the domain experts. Be smart about making the judgement.
Leadership is crucial in a flat hierarchy too. The team might start to lag behind, in which case, it is beneficial to step out of your role for a while and make things happen. To the external world, you are a team. What matters is the product that you deliver in the end. So, be prepared to take actions as needed which might be outside your domain.
Retrospectives can be useful to keep the team on the same page. Feedback to the teammates should however be constructive. A nice thank you can go a long way.
Conclusion
This list is obviously not exhaustive. Also, I did not include the technical knowledge I gathered in some new domains, e.g. app development with react-native. I believe it should be an inherent skill of a software engineer to be able to adapt to any given situation and learn whatever technology is needed.
A big “thank you” to the core team of Digital Product School for making it happen. I would strongly recommend Digital Product School to anybody who also wants to improve their skills in these areas.
Few more snaps
