Continuous Discovery in 2010
Continious Discovery Habits is a new trend. The one that I like. It structures knowledge into actionable steps that you can apply to shape your understanding of impacts, outcomes, opportunities, bets and outputs.
Recently, Radek Maziarka interviewed me (Polish) on a related topic.
In fact, CDH book didn’t invent continuous discovery.
Most methods cover a narrow scope. This one too. People tend to over-focus on discovering when thinking about continuous discovery, and then they perform very poorly on delivery/execution.
That’s why we need balance, common sense and experience.
I started my first official job as a software engineer in 2010. I was 20 years old shy person. In the first week, I got a computer. Also, a car keys, and I was asked to drive to our customers' headquarters alone to talk to them, understand them, feel their pains, and see how they use our product. That was stressful but valuable. Since this single event, I have always assumed that discovery is normal and neverending. As a software engineer, I learned analysis and discovery before I learned deployments. Today, I am super happy and proud that I had the opportunity to start my career in a company that valued understanding customer needs, pains and desires. The company that was not hidden behind the wall of the Internet.
The point is, if you do something that hasn’t been described in the book - it doesn’t mean you’re wrong. Everyone can write books and shape the world. So do you.
The way we worked in 2010 (thanks to my boss) deserves another article.
The explanation of why we at IT are not-so-good about onboarding new people to the industry, to the new team, why we fail in communicating the expectations, why we over-use poorly executed 1:1s and why we are overprotective, which slows the progress of people deserves yet another article.
What’s the single step you can do to get close to continuous discovery? Take 2 hours long customer success shift at your current company.