Week 10 — How can we learn the fastest?
Week 10, like the weeks before, had its interesting moments when sudden things appear and you’ll just have to adjust and shift accordingly. Thomas has done a remarkable job with creating both the product and the machine learning model behind it, but as the days drew closer towards the end of the week, we realized we are just not yet at that stage (in regards to proposition, design and development) when it would be the best use of our time to pilot the product outside the company.
Having put quite the time and effort into contacting companies and nagging people, canceling the pilot definitely felt like a bit of a personal bummer, but of course made all the sense in the world. It’s all about finding the quickest ways to learn and having the access to that rapid feedback loop. And, well, there were at least some lessons and practices learned about handling drawbacks in a professional manner and contacting all the stakeholders accordingly.
As we’ve moved forward with the project, it’s become more and more evident to me how important it would’ve been to include the machine learning aspect into our journey from the day one. Our process was dictated in the beginning by us trying to find the best possible problem regarding our space to solve, with a mindset that machine learning would be the means to an end — once we have the best problem out there, we can solve it in a unique manner with machine learning. Still doesn’t seem like a bad strategy on paper, but with the complexity of the modeling and how machine learning is intertwined with the UX of whatever we want to build, there easily becomes a mismatch of what we want to do and what we can do. Therefore really have to hand it to our Timmy-Tam who has been able to fight for the functionality throughout our journey!
Another personal learning touches upon having a clear vision in the team, and sticking to that — or at least not individually drifting into different directions. I suppose I should have taken a stronger stance as a product manager of the team in making sure that we are all present when discussions about the broader vision and the flow of our product is discussed, and ensuring that we all know what, who and when we should be listening to. When the product is in such a vulnerable, ugly baby state, it can be hard to defend it, and external opinions may receive a greater gravity than they should. In the end, the team itself is the one (and only) unit that has gathered all the research, all the insights and has embodied and internalized the reasons behind the product — but that itself is more like a mindset that’s developed throughout the journey, and before you reach the pitching and the final state, being able to verbally explain and defend it can be tricky. And when you waver in your reasoning, it’s quite easy for external forces to shake that base you have built and question whether there is enough insights behind it. Now that being said, obviously showing the product to people, listening to all kinds of opinions and learning from that is extremely important at all of the stages during the product development process, but I guess my argument is that there is a time and place for different kind of feedback — and if it is touching upon the fundamental founding and reasonings behind the product, the whole team should definitely be there to listen and comment. Confusion in the team can be a real pain in the butt.
So next week we will test codename “Block” at MxM! Looking forward to some interesting bugs to arise and having interviews with the users. It’s crazy how quickly the summer has gone :O!