As we enter a recession, the tech industry is in turmoil. Term sheets have been pulled, valuations cut, and founders scramble to reduce their burn
During heavy growth phases, we can sometimes spin up multiple new teams each month. We may try to onboard and organize those teams consistently, but more often they form organically, take on their own identity and culture, and mutate significantly from the teams you managed when your company was small.
Being able to quickly spin up effective teams is not only necessary to grow, it’s an existential imperative. After reaching product-market fit, the #1 reason growth stage companies fail is due to mismanaged growth.
Whether you know it or not, talent is your #1 problem right now. The COVID-19 lockdown has accelerated the Digitization of Everything. Every human interaction has gone online, so the demand for software engineers has exploded. With the transition to remote work, Big Tech has eaten up all the great talent.
If I had to pick one thing that every product team should do that would unlock the most inspiration, insight, and growth, it would be customer interviews. When clients ask me what they should be doing to build better products, I always tell them “Just start talking to customers!” Once they do, it becomes a wellspring of enlightenment, inspiration, and innovation.
I’m a voracious reader. When I approach any challenge with my teams or clients, I always look for a book or framework that helps frame the problem and guide me to the best solution. Here is my essential list of books for every agile practitioner.
At the end of every year, I spend the holidays reflecting on my year, what went well, what didn’t go well, and what I can do in the next year to be a better version of myself. I take all of my coaching clients through this process as well. This year, I decided to open-source my Personal Retrospective Guide so that everyone can benefit.
I’ve been leading and coaching software development teams for fifteen years, and there is one problem that has surfaced in some form in every single team I’ve ever worked with. The problem begins when the Product Owner asks the engineers to work on a vague story with very little context and no acceptance criteria. This is called Requirements Churn.
In agile development, we strive to maximize efficient output while maintaining a sustainable pace. It’s the team’s responsibility to constantly assess their capacity, take on work up to, but not exceeding their capacity, and consistently invest in continuous improvement to increase capacity over time.
If you’ve ever managed or built a product, you know that gathering and analyzing customer feedback is hard.
It’s time-consuming; you have to spend hours prospecting customers and following up to schedule interviews or collect surveys. More often than not, the responses received aren’t specific enough or lack the context necessary for in-depth analysis. Not only do you have to collect, clean, and organize your data, but you also need it to be relevant and meaningful. What if I told you that there was a better solution for this?
There’s nothing more inefficient than building the wrong things, so how do you know if your product features are going to make an impact? I’ve covered the Pirate Metrics framework as a way to evaluate and prioritize features from a business perspective, but what we really want to know is the impact a feature makes from the user’s perspective. For that, we need a slightly different model.