In the dynamic landscape of technological innovation, teams often find themselves caught on a treadmill of fulfilling customer requests without truly addressing their underlying needs. We were no different.  Here is what a typical conversation with my clients sounded like:

− Client: “Surya, as a Salesforce Release Manager, I am really interested to see how many deployments happen per week and what is the percentage of changes we are introducing. I would like your application to do it for me.”
− Me: “Sounds good Ben, I will add your request to the product backlog!”.
− My inner voice: “Uhh! And one more feature for our already packed backlog…”

Our growing backlog of customer requests and ideas started to hinder our ability to go fast and deliver real product innovations. I experienced a mix of frustration, determination, and hope. I needed a paradigm shift to really change. Here is how my team and I broke free from the feature factory model we had adopted despite ourselves.

The feature factory model and its limitations

Our focus was on delighting customers by actively seeking feedback and collecting their suggestions. However, over time, this led to a mountain of requests, creating pressure to deliver on all fronts. Many requests stagnated in the backlog because we were unable to tackle them all and had a hard time prioritizing them. What this meant was:

1. We became out of touch with the immediate market pulse

2. Older requests were much harder to analyze,

3. People who made the request may have moved on or forgotten why they asked in the first place

As an example, I recently spoke with a client who raised a request a long time ago but had completely forgotten about it because it had remained in our backlog for so long. When we finally got around to working on it, the client insisted that they still wanted it even though they couldn’t remember why. They could not explain some critical elements required for implementation because they had lost the context of their request. This made it difficult to define what to build for them.

The emphasis on shipping features quickly and without applying enough strategic thinking led us to release features that were not fully resolving the customers’ problems. This also comes with the internal practices we were following: in Agile, the role of PM/PO is limited to feeding stories to the development team with little focus on discovery. I felt disconnected from the true essence of innovation and the satisfaction of creating something meaningful. "I just want us to create something great together."

Recognizing the need for change

We were shipping lots of features but still hearing complaints from our customers, which made us question what we were doing. Realizing the inherent flaws in our approach, we embarked on a quest for a new direction. The catalyst for this transformation was an upcoming conference, providing the perfect opportunity to announce our reinvention and re-establish ourselves as game-changers in the industry. We aimed to have a wowing demo ready within one month, just in time for this conference. This product would be a brand-new addition to our Salesforce DevOps platform product family. While we had a name for it, Flow Center, our team started from scratch. It all began with a three-day workshop where we reconstructed our understanding of customers’ needs and the challenges they faced.

Embracing a Customer-Centric Approach

We took a bold step by delving into real customer stories across various industries, team sizes, and geographies. Through interviews, past experiences, and encounters with customers and sales representatives, our team gained invaluable insights with a focus on customer emotions. We picked twenty customers to interview. Here is what a few of them said to us:

• Ian, who was onboarded as Release Manager for three teams: “I want to ship features at speed.”
• Tim, Salesforce Manager who works with multiple Salesforce consulting partners: “I want to scale the team without losing deployment speed.”
• Jack, Release Manager who works with a small team: “I want to see how long it took for the user story to get to production and how safe the Salesforce code is.”

We knew that Flow Center could be a good solution to their problems. In the end, we realized they had a very similar challenge: move Salesforce code faster to production yet have control over quality. In lean design and development, we call this a “client trade-off”. The client trade-off is the product’s engineering challenge. It combines two ideas that seem opposed yet, together, are valuable to clients. A great trade-off is one that is not well-solved by existing solutions. Apple’s latest 15” MacBook Air is “Impressively big, impossibly thin”, a good example of a client trade-off.

This deeper understanding helped us categorize customers and identify a crucial job to be done (the progress they are striving for, its circumstances, and context – from Clayton M. Christensen's theory) to guide the product concept: alleviating the overwhelming sense of never-ending tasks and removing drudgery and anxiety from the lives of Salesforce DevOps teams. The emotion that we needed to touch was very clear, and we totally empathized with their struggles, frustrations, and desires for a better way of working.

Salesforce was built as a CRM and then ventured into becoming a development platform. Salesforce development is starkly different from traditional development and can get overwhelming at times for the users with not much control over certain aspects. Lack of visibility into all the connected pieces of the Salesforce ecosystem makes it even more challenging.

Discovering our trade secret

To translate this customer-centric vision into tangible engineering challenges, we aim to resolve the trade-offs customers faced when choosing between the company's offerings and the competitors’’. Having an upcoming deadline pushed us to make smarter decisions and find clever and pragmatic solutions. We had one month until the demo day. We narrowed our focus on what we believed would create a “wow” effect. To do this, we identified the main customer preferences based on our analysis of their feedback and translated those into a set of critical performance indicators for the product. Automation level, ease of use, security, and flexibility became our new guiding principles. Below is the radar of customer preferences that we built:

Then we compared Flow Center to competing solutions, and we realized that we were above everyone on the “ease of use” preference but still had ways to go on security and flexibility.

We tried to figure out how the product should behave in order to better satisfy these customers' key preferences. We came up with a few product critical performances and set targets to guide the development team during the design phase. These now constitute our “trade secret” so forgive me for not sharing them with you.

All this was very useful because, for the first time, the developers had more room to explore different solution designs to reach a product’s critical performance, instead of just coding a user story by following the PM’s step-by-step instructions.

Collaborative ideation and accelerated development

With the involvement of the entire team, a wave of creative ideas emerged, offering a range of opportunities to explore within a short timeframe. The discussions were filled with suggestions to save time and introduce innovative solutions, igniting the team's creative spirit.

The tools we used (such as “job to be done”, customer radar chart, product critical performance indicators, etc…) also served as a means of communication and collaboration within the team. I could now explain the problem we targeted to solve better. This ongoing collaborative approach has transformed the team from passive observers to actively engaged contributors. The process of collaborative ideation was not limited to formal meetings alone. Informal conversations in the hallway, impromptu discussions over lunch, and even late-night brainstorming sessions became integral parts of our accelerated development journey.

The diverse range of expertise within the team enabled us to approach challenges from multiple angles. Each team member brought their unique skill set, knowledge, and perspectives, creating a rich tapestry of ideas and solutions. The process of collaborative ideation was not without its challenges. Conflicting viewpoints, differing priorities, and occasional setbacks were all part of the journey. However, the team's commitment to open communication, active listening, and mutual respect allowed us to navigate through these obstacles and emerge stronger.  There were some cool ideas that came out such as using AI to elevate our constraints and using well-established data visualization tools to drastically decrease the time to market.

Achieving an impressive milestone

Despite the challenges faced along the way, with a team of five, we managed to develop a version of an amazing product in just 13 days, in time for the conference's demo day. This achievement wowed customers and provided a glimpse of the organization's potential. Encouraged by the success, the team is now working on a fully-fledged version of the product, set for release in the third quarter of this year. We maintain this spirit along the way by always going back to the product concept and critical performance indicators.

My role as a Product Manager becomes more about providing the frame that everyone uses to make their decisions, even though I still write user stories to some extent, this makes for a much better product. Breaking free from the customer stories model fostered a richer and more collaborative environment within the team. I wanted to do something different for this product, and together we succeeded. Flow Center was a smashing hit during the event!