Your product’s story is its design, its features, images and videos, quotes from customers, tips from reviewers, conversations with support agents. It’s the sum of what people see and feel about this thing that you’ve created.

Build, Tony Fadell

Products are ubiquitous, impacting every aspect of our lives. In his book Build, Tony Fadell beautifully summarizes this by saying, "Products are the sum of your design, features, customers, and your support agents." This book serves as a comprehensive guide for those who want to create, or as Tony puts it, build their own product.

Building a product is a journey with a definite beginning and end. At the start, clearly define your product. For insights on proper product definition, refer to our article "Is It a Thing? Demystifying the Essence of Product" which explores different perspectives from software professionals like QA, backend and frontend engineers, and product owners.

Throughout this journey, you'll acquire customers who interact with your product, be it on your website or directly. Customer feedback is crucial for driving product growth. Starting with a prototype or MVP (Minimum Viable Product) helps you understand your customers' experience early on.

You should be able to map out and visualize exactly how a customer discovers, considers, installs, uses, fixes, and even returns your product. It all matters.

Build, Tony Fadell

Understanding why people crave your product is key. As Tony Fadell emphasizes in his book Build, this forms the basis for understanding customer needs: "Understanding your customer—their demographics and psychographics, their wants and needs and pain points—is the foundation of your company. Your product, team, culture, sales, marketing, support, pricing—everything is shaped by that understanding." When you embrace this customer-centric approach, you view your product through their lens.

With a clear vision, the next step is analyzing your product. The crucial question becomes: "How can we effectively analyze it?" Finding the answer marks the second phase of product building. When I posed this question to my teammates, their enthusiastic responses excited me.

Let's start our product owners thought about the product analysis.

For me, product analysis starts with "sniffing the air." I am a deterministic person, and I believe that every action (open or hidden) has a reason. My first focus is to find this reason. Once I have identified the reason accurately enough, I start to examine the target market for the product's positioning. For this, I use various tools such as Google Trends and Semrush, as well as open-source intelligence (OSINT) techniques. The preliminary preparation and "benchmarking" phase, as I call it, forms the backbone of the process. After answering the "where are we going?" question as a product person, I move on to the product and feature derivation (contribution) phase. Here, I try to interfere as little as possible with the competencies of my colleagues, while at the same time making the most detailed conceptual and functional definitions. After the product is launched, I review my reasons for entering the market and evaluate the product-market fit. To do this, I try to get to market as early as possible and collect as much feedback as possible. I do this through digital products like Hotjar, Google Analytics, and Survicate, as well as by communicating directly with users.

Berkay Vuran, Product Owner

As a product manager, my approach to product analysis involves managing the end-to-end lifecycle of a product, making strategic decisions and adopting a customer-centric approach. The product's goals, target audience, needs, global trends, competitors and the focus of the intended product must be accurately analyzed. In alignment with this strategy, a roadmap is created by breaking down the product into the right components, analyzing which features will be included in the MVP, and determining which features will be added later.

There may always be factors influencing the next steps, and listening to customer feedback simultaneously is crucial for accurately analyzing them. Continuous feedback collection and maintaining strong communication with all stakeholders are important factors contributing to the accurate analysis of the product.

Of course, we always need to speak with data! It should be relied upon both to determine the needs of the emerging product by seeing pros and cons and to measure its performance and impact

Simay İşsever , Product Owner

Both Berkay and Simay emphasize the importance of understanding the "why" behind a product before diving into development. Berkay uses a detective-like approach to uncover user needs and market motivations, leveraging various tools and techniques. Simay takes a strategic, data-driven perspective, focusing on aligning product goals with target audience needs and global trends. Both highlight the continuous feedback loop, using user input and data to iterate and refine the product throughout its lifecycle.

To ensure an exceptional user experience, I think, a QA engineer's perspective is invaluable. The below response tells how QA approaches product analysis and offer valuable insights that complement our understanding.

If a product has a structure that includes an introduction, development and conclusion, I examine this structure from start to finish, and then I examine the functional and non-functional parts separately. as a result, I have a scenario that will be from end to end and an output that includes variables on a functional basis. Thanks to this analysis, it is easier for me to divide my test into parts and write scenarios. at the same time, I can calculate roughly what will take how much time.

Miraç alagaş, QA Engineer

Functionality is essential, but how do we make the product stand out? Arman, our Product Designer, shares his secrets for product analysis.

For a product analysis, you need two things:

1- Obtain the business goals and the purpose of the product from the stakeholders.

2- Conduct a comprehensive user research to reveal the users’ interaction with and expectations of the product. This will point out the differences between what the product was built for and how the users are actually using it.

Arman Kırım, Product Designer

Building on Arman's design vision, the Frontend Developer now explains how certain UI elements will be translated into code, considering performance, accessibility, and compatibility across different browsers.

Looking at things from the frontend perspective, when we analyze a product, we're diving into aspects like how the user interface is designed, the overall user experience, how easy it is to use, its performance, whether it plays nice with different browsers, how accessible it is, and how we keep an eye on errors. The main goal is to make the whole user journey better by concentrating on creating a UI that's user-friendly, ensuring it's easy to use, it runs fast, works well on different browsers, follows accessibility standards.

Basak Akman, Frontend Developer

Now that we know how users interact with the product, what happens behind the curtain? The Backend Developer takes us on a journey through the intricate world of servers, databases, and APIs that make the magic happen.

When analyzing a software product, several factors should be taken into consideration. As the first step, the business domain that the product aims to address must be well defined. What are the necessary conditions for the product to provide a high-quality solution? When determining requirements, analysis should be conducted not only technically but also on various aspects such as performance and security. Once the requirements are identified, functional and technical features that meet these requirements should be defined. As mentioned, a thorough analysis of the domain the product is trying to address is crucial, and the technology choice should align with this domain. The creation and clarification of flows on the system, known as use cases, are necessary. The impact of these flows on the system must be analyzed and clarified in a clear manner.

Eren Yılmaz, Backend Developer

Following the Backend Developer's focus on performance and scalability, the DevOps Engineer now explains how they will implement automated testing, continuous integration/continuous delivery (CI/CD) pipelines, and cloud infrastructure solutions to further optimize performance and handle growth.

Products have to be in fast-paced development in order to compete and create value. As a devops engineer, my main point while analyzing a product is to detect opportunities for automation and improvisation. With these improvements, product teams can deliver their tasks faster, and the product can keep growing. To do so, monitoring tools within our infrastructure were set up. To start improvising, we should first be able to see what should be optimized. We could detect bottlenecks. The bottlenecks can be slow deployments, scalability issues, and current infrastructures not supporting the products expected for fast-paced growth. Finally, after the detection of the issues, the DevOps team can start solving them.

Meriç Özkayagan, DevOps Engineer

After reading our teammates response, we summarize their response to similarities and differences between them. Why we analyze their question to separate differences and similarities, if you ask me, we can easily see the thing that we have to focus when start to build a product. Let's know the similarities and differences our teammates response in the below:

Similarities:

• Customer-centricity: All team members emphasize understanding user needs and expectations as a crucial aspect of product analysis.

• Data-driven approach: Using data (analytics tools, user feedback) to inform decisions is highlighted by several members.

• Iterative process: Continuously collecting feedback and adapting the product based on insights is mentioned by multiple individuals.

• Collaboration: Importance of communication and collaboration with stakeholders (users, other teams) is emphasized.

Differences:

• Focus: Each role naturally focuses on different aspects of the product:

  • Product Owners: Business goals, target audience, roadmap, MVP, product-market fit.

  • QA Engineer: Functional and non-functional aspects, test case development, time estimation.

  • Product Designer: User interface, user experience, usability, accessibility.

  • Frontend Developer: Similar focus to Product Designer, but with technical implementation concerns.

  • Backend Developer: Business domain analysis, technical requirements, performance, security, use cases.

  • DevOps Engineer: Automation opportunities, improvisation, infrastructure bottlenecks, fast-paced development.

If we demonstrate their similarities and differences on a table by their role, we reach the below table.

Similarities and Differences of Product Analysis Approaches by Title

While the core principles of product analysis - user-centricity, data-driven approach, iterative process, and collaboration - resonate across the team, each role naturally gravitates towards specific aspects based on their expertise. Product Owners like Berkay and Simay delve into user needs and market trends, shaping the product vision and roadmap. The QA Engineer, Miraç, dissects the product structure, ensuring functionality aligns with user expectations. Meanwhile, designers like Arman focus on user interaction and experience, crafting an intuitive and delightful interface.

On the technical side, Basak, the Frontend Developer, tackles the user interface's look and feel, while Eren, the Backend Developer, delves into performance, security, and technical feasibility. Meriç, the DevOps Engineer, focuses on optimizing development and infrastructure for rapid iteration and growth. These distinct perspectives, like instruments in an orchestra, weave together to form a holistic understanding of the product.

This diversity is crucial. Berkay's "sniffing the air" for user motivations wouldn't be as effective without Simay's data-driven insights. Likewise, Miraç's functional analysis thrives on Basak's understanding of user interaction. Ultimately, it's this harmonious blend of perspectives that ensures a product resonates with its audience, fulfills its technical potential, and achieves long-term success.

Despite their unique areas of expertise, all team members sing from the same hymnal in their approach to product analysis. The melody of customer-centricity resonates throughout, with everyone, from Berkay, the Product Owner, sniffing out user needs, to Arman, the Product Designer, crafting user-centered experiences. Data acts as the rhythmic foundation, guiding decisions for Simay (Product Owner) in crafting the roadmap, and informing Eren (Backend Developer) about technical feasibility.

The iterative process weaves its way through each role, like a recurring motif. Miraç, the QA Engineer, continuously refines test cases based on feedback, while Meriç, the DevOps Engineer, optimizes infrastructure for rapid iteration. Collaboration forms the harmonious chords, with Basak (Frontend Developer) translating design ideas into user interfaces, and Eren (Backend Developer) ensuring technical solutions align with product vision.

This shared commitment to core principles ensures a symphony of success. Data insights from Simay inform Berkay's market analysis, while Miraç's functional testing complements Arman's user experience focus. Ultimately, each team member's unique voice blends to create a rich and comprehensive product analysis, ensuring the final product resonates with users, functions flawlessly, and adapts to ever-changing needs.

Understanding your teammates' perspectives on product meaning is crucial when building something as a team. This shared understanding, as evidenced by our recent product analysis, allows us to create well-rounded, user-centric solutions. For example, Berkay's focus on user motivations helped us identify a key unmet need, while Eren's technical expertise ensured our solution was both affordable and practical. This collaboration truly embodies the 'build the team before building the product' philosophy. While the solo approach might be tempting, facing diverse customer needs requires the combined strengths of various roles. Just like a well-oiled machine, our team's diverse perspectives fueled a comprehensive product analysis, ensuring we're on the right track to solving real problems for our users

Products play a crucial role, and storytelling is an essential element of their success. Before concluding my article, I want to share a thought from Morgan Housel's book Same as Ever book:

"Not the best idea, or the right idea, or the most rational idea. Just whoever tells a story that catches people’s attention and gets them to nod their heads is the one who tends to be rewarded."