Turning (Feature) Factories into Gardens
Or how to escape the feature factory and turn it into a wholesome environment!
This article originally appeared on Mind the Product, and is republished here with extra content. Take it as an example of how story-telling can transform the way you and others work, with some more concrete advice on what you can try to improve.
If you’d like to listen to the podcast about it, it’s here.
Rivers of toxic waste have been written about feature factories, and I won’t add to them. Instead, I’d like to offer you three ideas to help you deal with such situations. First, I’ll suggest an alternative mental model to product development, then we’ll separate hype from hyperbole, and lastly, I’ll share some practical advice for those stuck in a factory and are wanting to do better.
Factories vs Gardens
The word “factory” evokes a sense of machinery, grease, smoke, and noise, though the point of the analogy is about the production line. Itamar Gilad has recently published a post about feature factories that explains the issues with this approach. The short version is factories are managed as ‘input > process > output’. Management has always been concerned about increasing efficiencies, meaning more output units for fewer inputs at a better rate.
Sounds familiar? Have you been asked to deliver more features faster with fewer resources? When we’re working on developing software, especially SaaS platforms, it has been shown time and time again that piling up features often causes long-term harm. The features often don’t have the impact we hoped for (20% of features account for 80% of customer value), and the bulk are slowing us down with tech debt. If we don’t know the why and what for, we’re like that sign at my favourite coffee shop – doing stupid things faster and with more energy.
Instead, think of your platform as a city garden. You never “ship it” to customers. Rather, you invite people over. In Jobs-to-be-Done terms, people will ‘hire’ your garden when they need to do something – a family picnic or outdoor sports.
Your job as the landscaping architect (aka product manager), is to understand what people need and want and then provide it in a way that engages, is easy to use, and creates value. And like a city garden, your product is always changing. You can chart and pave the paths, but a year later you notice tracks across the grass where people routinely walk (some features are more heavily used than others, and some are used in unanticipated ways). Or you notice a decline in visitors as they move to parks with playgrounds (competitive landscape changes), or the city council demands safer playground equipment (legislation changes).
So instead of “shipping features”, an analogy which wrongly equates ‘features’ with production units, think of your product as a continually evolving park, where you constantly need to weed and prune, adapt to user demands, build new attractions, and replace or retire the disused ones that cost you maintenance. You do that by understanding your target audience, how what they value changes over time, and how to engage them (our park is for families with kids, so we build safe playgrounds and BBQ areas – we’re happy to let the sport-nuts go to that other park, and not compete with their off-road bike courses).
The dangers of hyperbole
Much of the product management advice comes out of – and is geared towards – Silicon Valley start-ups or Big Tech. These are extreme ends, and most worldwide product development (and therefore the majority of work environments for product managers) is vastly different.
Start-ups have a runway to figure out how to build a viable business or crash. Product discovery becomes a do-or-die proposition. As the company grows and acquires customers, you build up the knowledge of the market, your capabilities, and your niche. But this knowledge comes with demands, and you need to keep servicing existing customers.
Features come in different flavours: from bets on unknowns to incremental improvements. In our analogy, we could work on a new BBQ area, vs add a slide to the playground, vs bigger parking. Problem discovery becomes solution discovery, and then just build-to-requirements. Parking is required, but fancy parking won’t improve attendance. For those interested in theory, read about the Kano model.
Big Tech, at the other end of the scale, has resources to throw at the problem. They can both build up tooling you can only dream about and afford to place many more bets and see them fail. They also tend to put out articles that are more marketing for new talent than a realistic depiction of how development actually works. The Spotify model[2] is a prime example of ‘some of the dev groups kinda worked this way for a short period.’
So, read up on trends, tools, frameworks, and ideas. Just don’t think that if someone wrote about their success with it then it will work for you in the same way, or that indeed the article was an accurate and full description of reality across the organisation.
‘Process’ has become a dirty word, and I predict ‘framework’ will go the same way. Ideas and principles adapted to your unique circumstances will give you more bang for your buck. Sometimes it’s about figuring out what to build and sometimes it’s about cranking features to keep paying customers happy. Knowing which is which, is an exercise in maturity.
Making your factory into a garden
Now you have a better mental model to map where you are (what kind of features you need) relative to what’s important (because it’s always about servicing the customer segment as a viable business), and you also know not to believe everything you read on the internet (because it might be an exaggeration). But what should you do if you find yourself mired in a ‘just build what I say as fast you can’ environment?
Starting with what not to do…
Don’t just complain.
Constant whines about ‘the right way’ won’t get you far, neither in your company nor in your next interview. I can guarantee you have more agency and leeway than you think you do, and the best way to utilise it is to become subversive. Not in a Molotov cocktail kind of way, but by showcasing the right thinking within the boundaries of prescription.
First, you must speak with customers.
Find any excuse. Volunteer to help sales with pre-sales demos; help with post-sales installation and training; go to conferences or visit user forums; offer Support to speak with the angry customers (gotta love them – they take the time to complain, rather than quietly move to your competitors!).
Find any excuse, and when you’re there have a short chat with the users and buyers about their particular environment and circumstances (“Before we dive into the demo, can you just give me a brief explanation of how you work? It will help me solve the issue”). You’ll quickly find that those 10-minute discussions help you build empathy and understanding, and are well worth the rest of the hour on the ‘official’ reason you’re there. You’ll be able to represent the customer internally, and carry intelligent conversations with stakeholders and directors who are already familiar with the customer needs.
Second, treat every internal stakeholder as a customer.
You love your customers and their problems, right? Apply the same mindset to your stakeholders (Sales, Support, and Executives). You’ll likely find that they have their own insights into customer needs you can learn from. Never discount the SME’s opinion as wrong, just because it didn’t come through ‘proper’ product management processes.
Build empathy by being helpful, leading the business on the ‘right’ path of product management by example, and learning and guiding simultaneously. ‘Productise’ yourself and your product management offering, and tailor it to your business by addressing the ‘customer’ needs.
“The TPS report need a new cover sheet? Can you tell me a bit more about what we’re trying to achieve with that? Do you mind if I speak to the customer directly – just to make sure they’re happy, of course.”
Or, “Can you please help me review this one-page summary for the data-lake-house you wanted? I’m trying to identify the success criteria, so the devs know what to build without blowing the budget.”
And, “While we’re at it, can you help me with these other one-pagers? We heard customers talk about them, and I need help with the numbers to see if we can make money off the ideas.”
In summary
Don’t think about “features” as consumable production units. Think about a live garden, constantly evolving and growing, and how to make your target audience love to come there.
Realise that products go through life-cycles, and sometimes just building features is important. Are we figuring out if a gazebo for school band performances will draw more visitors, or do we want to build a second flying fox where there’s always a queue? Did the regulations change and do we need to put protective flooring? Or do we have the budget to explore a water-slide?
Be as subversively helpful as you can, insinuate yourself into every opportunity to speak with customers, and show people that by using data and templates, you can have better discussions around product management. You may or may not affect a grass-root cultural change in your organisation, but you’ll certainly learn and be able to talk about it in your next interview.
Meta-Summary
(Small-m meta 😉) This is an example of storytelling for business. Using analogies and metaphors, paying attention to language, adaptively trying new approaches to deliver the message — are all useful tools in Product Management. The above example is aimed at giving you tools to align your company and organisation by providing a shared understanding. Humans relate better to such stories than the soapbox of “But Marty Cagan said that’s not how to do it!”
So whenever you’re faced with a situation where you’re struggling to communicate your message, first stop and listen. Then, if you’re blocked from accessing customers for any reason, be as subversively helpful as you can. Volunteer to assist in any way that puts you in front of customers so you can get familiar with their context.
Once you’ve built an understanding of the other stakeholder’s point of view and pain points as well as the customer circumstances, try an analogy. If it doesn’t resonate, try another. Find a story you can both connect to and then build upon it. Use these metaphors as rallying points for the team, as well as for yourself.