In far 2010 googlers introduced design sprints to the tech product world. The idea is simple: Map → Sketch → Decide → Prototype → Test. Read more here and let's move on.
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.
Communication is always an issue for all teams, especially those working in creative domains like IT. Designers, developers, and content creators often face problems of not knowing how to accept feedback and, more of an issue, how to give it to others. And Radical Candor, introduced by Kim Scott, is salvation for this.
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)
Я глубоком детстве я обожал читать. Начал рано, мог проглатывать по 2-3 книги в неделю. А дальше примерно с университетских годов и на пару лет я перестал читать практически совсем (пара книг в год, не больше). И в какой-то момент решил, что так не пойдет, надо начинать любить читать снова. И как-то сама собой выработалась некая, в общем-то, открытая критике и предложениям практика.
«Человек должен быть достаточно одинок, чтобы вдумчиво прочитать эту книгу» — непрямая цитата из фильма The End of The Tour, байопик об авторе книги.