When talking about Job To Be Done, most people focus on theory or format and less on how to do research in order to derive these jobs. The most common (and I think effective way) is through user interviews.
A great book on the subject is “The Mom Test”. I’ve read it recently and found it to be complementary to the practice of JTBD. Here is a good summary of the book: https://lnkd.in/ercETMx.
Excelente artigo sobre como as empresas podem estar fazendo uso indevido de OKRs de Itamar Gilad. Link: https://itamargilad.com/5-ways-your-company-may-be-misusing-okrs/
Gilad lista 5 usos indevidos comuns de OKRs:
1. Usando OKRs para expressar um plano (OKRs baseados em entregas e não resultados)
2. Usando OKRs não S.M.A.R.T.
3. Excesso de OKRs
4. OKRs top-down
5. Usando OKRs para avaliação de desempenho
Outro erro comum que as equipes cometem:
6. Não saber a diferença entre leading e lagging indicators (indicadores adiantados e atrasados).
Tim Herbig escreve sobre isso: https://herbig.co/leading-lagging-indicators-okrs/
No artigo acima, Herbig destaca algumas das diferenças entre esses tipos de indicadores. 1…
JTBD ganha cada vez mais popularidade enquanto modelo mental para expressar oportunidades e problemas, mas entender JTBD e como aplicá-lo na prática parece ser um desafio pra muitos times de produto. Na minha opinião a dúvida aparece ao tentar entedê-lo inicialmente como uma ferramenta ou framework ao invés de interpretá-lo como um modelo mental.
JTBD está no mesmo nível de abstração que Problema ou Oportunidade… Ex. ao invés de pensar na dicotomia do Problema vs Solução, você poderia pensar em JTBD vs Solução. Outra coisa que o torna difícil de entender é que existem vertentes e graus de profundidade diferentes…
A friend of mine asked me how are Jobs-To-Be-Done and User Stories different. I fear I gave him the wrong answer. I said that Jobs-To-Be-Done is a way to map a user’s decision process for executing a job in order to uncover the user’s needs. I think that’s a simplification and an acceptable definition. …
In my last post, I wrote about assumptions, hypothesis and touched a little on experiments. I also discussed about how you, your team and stakeholders should always be mindful of the differences between problem space and solution space (part 1).
So by now you’re convinced that before investing time and resource in development you should gather evidence about the product you and your company wish to build. If not, take a look at this article: https://www.cbinsights.com/research/startup-failure-reasons-top/. …
In the last post we established that when you and your company are trying to create a product, more often than not, problem and solutions get mixed up and that you your biases, company culture and other forces will try to pull you away from the problem space and into the solution space. Don’t allow that to happen!
In the journey to understand Hypothesis Driven Development, Lean Startup and related ideas I have found that both problem and solution need to be validated and that there is a large amount of tools and content to help (and sometimes confuse) you…
On my last post, I talked about Hypothesis Drive Development and the benefits of asking yourself if your assumptions about a product or feature are correct before you dive into discovering the solutions and building on those assumptions. On this post, I thought I would talk a little about the high level questions you should be concerned about when building your products and features. If you are interested on more objective content, skip the first few paragraphs.
For some time now we have seen startups and enthusiasts talk about concepts like MVP, Lean, Value Proposition, Business Model canvas in relation…
A principle concept — and to me the first thing to keep in mind — about Hypothesis Driven Development and Lean Startup is that we are all delusional about our products and we must validate our assumptions. So before learning about discovery techniques, all of us can benefit from training our minds to admit that you should test your assumptions about your product.
In order to maintain this Hypothesis mindset, I always keep in mind 2 things:
1 — Every time you find out that your assumptions about a product or feature is wrong you have saved resources (time and…
I have years of experience as a software developer, team leader, entrepreneur and have transitioned to product manager in the recent years. My main drive throughout my entire carrier has been to create new and useful digital products for end-users and client companies alike.
I am currently product manager at Grupo JCPM, one of the biggest investment holding companies in northeastern Brasil. Our company invest and owns businesses in 3 major industries: real-estate, shopping malls, news and communications and is now investing in Digital Products. In order to create new Digital Products that support current subsidiary companies, the group has created a innovation team that is charged with developing and growing these products. The main product I am working on is a ecommerce marketplace for the group’s shopping malls.
Software Developer, former entrepreneur, product manager