Product development: or how to turn factories into gardens

In this article, product leader Assaph Mehr puts forward an alternative mental model for product development – think about building a garden not a factory

So much has been written about feature factories, I won’t add to it. 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 I’ll separate the hype from hyperbole, lastly I’ll share some practical advice for those stuck in a factory who want to do better.

Factories vs gardens

The word “factory” evokes machinery, grease, smoke, and noise, though the point of the analogy is the production line. Product coach and author Itamar Gilad recently published a post on feature factories, Feature factories vs value generators, that explains his issues with this approach. The short version is that factories are managed as “input > process > output”. Management is 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? It’s been shown time and again that piling up features often causes long-term harm when we develop software, especially SaaS platforms. The features often don’t have the impact we hoped for (20% of features account for 80% of customer value), and the bulk of them slow 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 sports nuts go to that other park, and not compete with their off-road bike course).

The dangers of hyperbole

Much of the product management advice comes out of – and is geared towards – Silicon Valley startups or Big Tech. These are extreme ends, and most product development (and therefore the majority of work environments for product managers) is vastly different.

In a startup you 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, or add a slide to the playground, or work on 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 on 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 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, 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.

Turning 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). 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 whining 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 use 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 (you’ve 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 to 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, 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, both learning and guiding at the same time. “Productise” yourself and your product management offering, and tailor it to your business by addressing the “customer” needs.

“The TPS reports need a cover sheet? Can you tell me a bit more about what we’re trying to achieve with that? 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 lifecycles, 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 zip line where there’s always a queue? Did the regulations change and we need to put protective flooring, or do we have the budget to explore a waterslide?

Be as subversively helpful as you can, insinuate yourself into every opportunity to speak with customers, and show people by using data and templates how 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.