Back in the day, I was a tester for a board game (a physical one) that my friend had been creating. After a few sessions, I noticed how I complain about issues with the game. I noticed that I express my feeling not offering solutions, but problem statements. Like "I feel the lack of a social component in the game" instead of "You should add the option of players working together against somebody." The reason is that I do not want the mentioned option. I wanted "a social component" to see in the game. And being honest with myself, I would better see an unexpected solution than one offered by me. In that case, it would be much more interesting to discover. In comparison with my ideas that I'm not even sure I would love anyway. Moreover...
In one of the teams I had been working with some time ago, I had a couple of disputes about hypotheses, analytics, researches, and how all of these shapes the better experiment-based desicions. My point was “proven” statistically: form a hypothesis, outline its metrics, develop, launch, and if p < α (success), roll it out. The problem is that I had not considered that this team was working in an early stage sturtup. A few months later, I started to see the flaw in my arguments hiding in the difference in how startups and big businesses answer the question “Why to do an experiment?”. And it’s all about how much everybody can lose.
There is a looming consistency in how JTBDs and Loops (retention, activation, game loops, whatever) look-alike in a nutshell. In contrast with User Stories, which have no clear start (why do we call them "stories" then?), JTBDs open any job with a well-defined prologue "When …" As Loops do so starting with a user's mental model, which is going to be changed by action and feedback. Combine it with Arcs (one-cycle Loops), and you will get the idea of the story that users go through exploiting your product. It's not about using a feature to do something but about ever-changing users' mental models.
I bet you were in situations of regretting not saying something. Sometimes in those where you should have said tough “No!” Every so often, as a Product Manager or whatever product-related position you take. Say “No!” to your boss, a big customer, a teammate regarding a new fancy feature. It’s always much easier to say “Yes!”. That’s when the feature prostitution starts and priorities blur as oil patches on the water surface. And being prepared means having some rules when to refuse.
The coolest part of working in IT is MVP creating—a mass of ambiguity when every right way to go is one of the thousands of the same rightness. Test, throw away, and forget as a bad dream making a new prototype. But no fun is endless; after that, any product team should see the whole picture of where to go next in the most transparent way possible. The prioritization has begun.
How boys release: the impulse to add a feature → release
How men release: use HADI (Hypothesis →Action → Data → Insights)
Everybody likes cinematography. Somebody perceives it as entertainment only. Another group of people works in this industry. But as being a Designer you just can’t miss the opportunity to learn something from movies (yeah, there is so much stuff to grasp of). And yep, as you have guessed already, I am a big moviegoer (if you can read in Russian, you are welcome to my Telegram channel Douglas Firs, or just check out my Letterboxd). Anyway, let’s dive into it!
As designers, we need to trace how our design will be implemented. We need to collaborate with many teams and especially the team of developers. All these people have their own areas of responsibilities, and we must strive to not get in the way of them. But we need to prepare the ground, so they would not do something unpredictable and wrong with the results of our work. And I don’t speak in terms of arrogance now. No. I just want to say all things (bad or good) which can happen with our design when we have passed it, for instance, to developers depends only on ourselves.