Idea to Product – Freshworks’ Style of Building Products
Founded in 2010, Freshworks is a global SaaS firm that provides customer engagement solutions for organizations of all sizes. The firm entered India’s unicorn club (start-ups valued at or above USD 1 billion) in July 2018.
The firm has grown from a 6 member team in 2010 to a 2500+ member strong company and has a dozen products under the Freshworks brand. Throughout this epic journey with a lot of growth milestones, the firm has also built processes that helped it scale while being true to the core brand promise of Freshworks of providing ‘Customer-for-life software’. One such key process is i2p (idea to product), the Freshworks way of building products.
Building the Right Product
Building a product is fundamentally different from servicing clients in the services industry. In services based firms, the requirements are clear from the customer and the firm is expected to build the solution within the stipulated time frame and budget. On the contrary, product firms need to formulate their own vision of what the customer needs and wants. This includes both explicitly stated needs and the unmet & latent customer needs. It is when the product firm delivers on a slew of these customer needs, a moment of wow is created for its customers – something that we at Freshworks aspire to do, day in and day out.
Should it be built?
The key is to start with the ‘Why’. To dig deeper into the problem and answer in concise terms, why does a certain problem need to be addressed or a certain solution need to be built. What exactly will get solved if the problem is addressed? What is the target market for this solution and what is the size of the opportunity? This is the most critical and the most difficult part in the overall product building process.
Output of this step: The ‘Why’ of the problem.
Product managers along with engineers go on exploratory calls and customer interviews to unearth the ‘Voice of Customer’. To understand the exact nature of the problem and collect feedback on existing solutions. The key here is to separate the problem from the suggested solutions by the customers. This is an important distinction: Though customers know the exact nature of the problems they are facing, they necessarily do not know what kinds of solutions will address the problem effectively.
If this process of unearthing the customer’s voice is done correctly, what emerges will be a concise problem statement that affects thousands of customers across geographies, market segments, and industries. Not a customer-specific problem. It is important not to take up a problem statement that is too narrow in its scope as the impact of the solution developed will also be handicapped to that extent.
Output of this step: The Voice of Customer
“If I had only one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution.” – Albert Einstein
Once the problem is clearly stated in unambiguous terms, the next step is coming up with different options of solutions and choosing the one that addresses the problem in the broadest sense possible. A solution that will be applicable across various dimensions such as geography, org size, limited to zero impact on existing product features, scalable with time, etc.
Output of this step: The optimal solution design
Once the solution is identified, the next step is to develop an MVP, a Minimum Viable Product with just enough features to create customer value and drive engagement.
Output of this step: A Minimum Viable Product
User Experience Design
The next step in the process will be to come up with high-fidelity mock-ups with probable user interface and experience. It helps a lot to give structure to an abstract idea in the mind of a product manager. It also helps in conveying a clear visual design to engineers and in showing customers the layout, navigation buttons, and form elements and how all of these form a whole picture.
Can it be built?
After finalizing the problem statement, the functional requirements, and solution design, the next step in the process is to do technical feasibility analysis and non-functional requirements (NFRs). Both these elements are critical to ensure the solution’s usability and effectiveness.
Technical Feasibility
- Should a new technology be considered for implementation?
- Are there dependencies for implementation with other teams?
- Does it impact existing architecture?
- Can any existing implementation be reused?
Non-Functional requirements
- How scalable is the current solution? Can more users be serviced or more data processed without having a negative impact on the performance?
- How are the other quality attributes such as security, availability, performance, reliability, etc. taken care of?
Though one can take an adaptive and incremental approach to defining and implementing these NFR attributes, considering all the factors upfront to avoid the risk of delivering an unsatisfactory product is highly prudent. This will reduce the chances of the product/solution being underused or not adopted at all or any major technical debt coming up later on.
Bringing Engineers Closer To Customers
In this entire process, engineers need to be involved from the very beginning. One needs to sell the big picture and the business value to the engineers. The key here is that, at the end of this exercise, not all issues need to be ironed out. The idea is to provide just enough clarity and direction to the engineers to start. And ensure there is a lot of room for learning and innovation during the actual feature build. This kind of ownership creates passion and passionate employees create outstanding products.
Summary
These are the essential steps in any successful feature development. The important thing is being nimble throughout and make each of the teams act as a start-up of its own. When done effectively, this gives us the following benefits:
- Gives more clarity on the requirements & technical approach
- Help understand the complete scope & come up with an MVP plan
- Dependencies are handled better
- Helps in being more realistic in coming up with incremental release plans
- The team gets the big picture & promotes ownership
- Gives a lot more clarity & freedom to experiment/innovate when development starts
Focusing on putting together this kind of plan before jumping to start developing has proven to be very effective in our quest to deliver WOW moments to our customers. There are many such initiatives that have proven to be very effective for us. We will see more about them in the upcoming series.
