Your inbox is overflowing with feature requests from every corner of your organization, the product enhancements you’ve committed to for the quarter are hopelessly behind schedule, and your development team is struggling with simple changes due to the complexity of your legacy product. Sound familiar?
Instead, I want you to imagine…nothing. Just a blank slate that you can form any way you choose.
When I landed a job at Stryber, a venture portfolio builder, I was eager to start working on Greenfield projects. The term Greenfield, originally used to describe undeveloped land, meant in this context the opportunity to build completely new digital products, so I envisioned a higher degree of freedom, an intense team connection and a lack of technical barriers.
During the past year, my experience working in new product development has revealed a whole new set of challenges, most of which were welcome and others that made me face the reality of what that blank slate really means.
Keep reading to find out where the fantasy of Greenfield does not meet the reality, where one fantasy comes true, but brings some surprising negatives along with it, and finally, where Greenfield met my expectations fully.
Being a pessimist, I always prefer to hear the bad news first. Let’s explore some downsides of Greenfield.
At the beginning of anything new, there’s an idea. That idea generally has to pass a validation or discovery phase to determine whether it has the potential to be a viable business model that solves a real customer problem. If you work in product management, this probably sounds like a typical evaluation phase for any new feature.
But in Greenfield product discovery, my team and I make big assumptions about absolutely everything: who the potential customers are, which business model and pricing strategy to select, what type of product and features to build and which channels to use to acquire customers.
I generally lack the internal data on which to base prioritization decisions as well as the existing customers with whom I can explore new feature ideas. As a result, a lot more time is invested in gaining knowledge and gathering data about the customer and the market before I can start proving product hypotheses.
As all product people do, I regularly encounter new challenges that are outside of my official realm of responsibility. When that happens in established products, there are at least some proven processes to fall back on.
Unfortunately, that safety net disappears when in the beginning stages of a new product. Fires need to be put out and, unless a start-up is extremely well-funded, there won’t be nearly enough staff to cover everything. I may be called in to dive into sales, customer communication or operational topics. New product development tests my perseverance, and requires both research and legwork.
But then again, if you are easily frustrated or do not like having to deal with issues outside of your area of expertise, you’re probably not a product manager to begin with.
In some instances, the positives have created new negatives.
If you are currently working on a product that’s been around longer than a few years, you are probably no stranger to legacy products. It is more than just legacy code slowing down your development and upping the potential for bugs. It may also include outdated features that are costing a lot of time and effort to keep alive.
In practice, companies unfortunately tend to keep such features running, even if they are unprofitable, simply because the organizational strain of killing them can appear to be more taxing than simply continuing to keep them afloat.
As Sally Foote said in her presentation about managing legacy tech, we in Greenfield “are building the legacy tech of the future”. And, at least for now, that’s a pretty great feeling. Developers get to write the first lines of code for the product. And, as a product owner, I can work with UX to create a simple yet beautiful product using methodologies I believe in. It is a huge opportunity to do all the things I wished my predecessors had considered when I was working on a legacy product.
But fresh starts do come with some disadvantages. More advanced technical solutions may initially be out of reach for new products, especially if the goal is to bring them to market in a very short time period. Creating a sophisticated AI solution is difficult if you do not start with a large collection of data or rely on support from third-party providers. Using a lean philosophy, we might instead initially utilize a basic algorithm and then work to obtain enough meaningful data to train a machine learning model.
From a product perspective, simplicity also has its downsides. I am focused on validating or invalidating a specific set of hypotheses and, once I have done that, I move on to the next set. While I still have a bigger vision of how the product could evolve, a roadmap does not carry as much importance as it might for long-standing product companies. Instead of compiling a long list of ideas that I plan to test or build in the upcoming months or even in the next year, I find myself focusing less on what might come next because of the propensity for change. A/B testing and experimentation are still valuable tools, but we are not yet in the phase where incremental optimization of conversion funnels or building features specifically designed for retention take precedence.
Everything may not have turned out exactly as I envisioned it, but some assumptions I had about building Greenfield products turned out to be absolutely true.
In an environment with a complex legacy product, each development decision is a costly, high-stakes investment. Established product companies may have already experienced too many half-built features and thus have a significantly lower acceptance of so-called MVP solutions. They are not willing to accept a lack of automation because of the strain it may put on internal operations teams. In addition, fear of losing existing customers’ trust understandably leads to the demand for a bug-free, risk-free launch, which can generally only be accomplished by compromising speed.
In Greenfield, scalability and automation take a backseat to speed and pragmatism — at least initially. I am not held down by high complexity but instead focus on what’s most important and decide on the leanest version of testing it without compromising user value. If the product concept is simple enough, I can get creative and build a fully functioning product using a combination of no code tools, and bring this to the market to test. By maintaining a customer-centric focus even without full automation, I can validate quickly while taking a minimum amount of risk because I know the solution can be engineered for a larger audience if it is successful.
Another common challenge of product teams in established companies is the flow of customer feedback. Sales might share feedback from prospects that is significantly different than feedback from those working very closely with existing customers. Filtering of feedback by various departments also leads to a potential for bias. The job of collecting and transforming it into valuable outcomes is often a slow and arduous task.
Just like in established products, my team and I collect customer feedback on our new product early and often and make sure it’s centralized. But luckily, such measures are not nearly as difficult to achieve in the early stages of a new product. Team members are hyper-focused on the customer and are exchanging information around customer learnings that will directly flow into new product, marketing or operational changes.
Since there are very clear goals for the first release(s) of a new product and I typically don’t have a huge backlog of such customer requests, prioritization is easier and I can shift focus or pivot if necessary without worrying about too many unintended consequences.
While I sometimes miss the organizational challenges that more established products present, I’m glad to have traded this world for one in which I can have a bigger hand at forming the initial product, can experience fulfilling partnerships with teammates from different disciplines and am enabled to quickly iterate for the benefit of the user.