Besides sharing their own expertise with me and the audience, we try to understand the recipe for their success and do what us project managers do best: break their success down into manageable chunks and see how we can take similar steps.
Event details: Thank you to Product School for the invitation to share this important topic with an active community of learners. The virtual conference platform used Hopin with 4,000+ live viewers at a given time for the sessions (around 20,000 total).
This guideline pops up often inside Automattic via folks like Matt, or me, on internal memos when discussing how best to balance product planning, strategy, and execution. With a bias toward action, we aim to learn more quickly by launching directly to users and customers.
I love this philosophy for product strategy and execution because it puts the right balance on each activity.
Dreams take time and effort to accomplish, and a clear product vision means looking ahead enough to inspire and motivate people to join the mission.
When we don’t know an accurate launch date at the beginning, monthly plans split the work into smaller projects and tasks that’ll bring improvements out to the public quicker. This means we learn faster, measure the immediate impact of a launch, and track usage as close as possible to real-time.
Speed matters in marketing, business, and product development. Sometimes we aren’t confident the current change is the right one, yet shipping before we’re fully confident leads to a smarter set of next changes — informed by the people using the product.
Ship daily, measure weekly, and plan in months to find out what works sooner than later.
In The big secret of small improvements Tal Bereznitskey explains how to improve “quick fix days,” where software teams take time to make small improvements. Those small changes can together mean a big win for customers and the business.
At Automattic we’ve experimented with both 1-day bug scrubs in one team all the way up to a full “hack week” — so Tal’s principles strike a chord with me.
Framing the problem is halfway to solving it — I love how he suggests rewording the subject line of a software change to fix a bug as something actionable, not just a description of the problem.
6. Well defined. Only work on tasks that are defined properly. Prefer “Make content scrollable” over “Bug: can’t see content when scrolling”.
Create positive feedback loops — I remember during my days answering WordPress.com Themes bug reports and how rewarding it was to hear directly from the people I helped with a bug fix.
7. Thanks you. There’s nothing like hearing a customer say “Thank you!”. When a quick-fix was suggested by a customer, let the developer email him and tell him the good news.
This is the work: customer kindness — Our latest iteration at Automattic speaks to this customer focus as the goal of the maintenance work — it isn’t just polish or cleanup, this is the product work. We even have a fun acronym for it now! H.A.C.K. — Helping Acts of Customer Kindness.
I’m a fan of Oblique Strategies for triggering a new perspective when I get stuck. To me this method brings active questions to trigger better thinking.
This practice comes up for me frequently in product management when working on both short and long views of a roadmap. As part of any decision making process, whether by myself for reflection, or in a team working on a product change, I might ask something like:
What is the end result for our customers? Where are we going in the long term?
The purpose of active questions, like Oblique Strategies, is to trigger more questions until you get a better answer. A truer answer. An honest answer. To find the why is to find the signal that drives everything else forward.
Who is it for? How will they understand it’s for them? How will we know if it’s a success? What do we expect to see change? How are we measuring it? What would be a surprise here; something that we don’t expect? Have we considered doing the opposite? Who has the most to gain? What’s the context?