The product lessons no one talks about – real insights from Boldare at Scrum Summit 2025, by co-CEO Anna Zarudzka

From features to products: the start of Boldare’s journey - discover Anna Zarudzka’s perspective

When I look back at Boldare’s journey, one thing stands out: how easily it’s possible to lose your strong product DNA, and how, at times, it takes a crisis to bring it back. Our path hasn’t been linear, but it’s been full of discoveries, hard lessons, and the relentless drive to create products that truly matter – to our clients, their users, and their business.

I’m not a product person by education. My background is in film, but over the past 20 years, I’ve worked closely with clients on over 100 products across three different continents. This unique position has allowed me to witness the full product lifecycle, giving me a first-hand view of the market, cycles, and the challenges that come with creating real value. Yes, many of the insights I’m sharing are subjective – shaped by my own experiences in a constantly evolving business landscape.

Over 11 years ago, when software houses were just starting to learn how to speak “product” instead of “feature,” we at Boldare decided to go beyond the buzzwords. We didn’t just talk about product thinking, we lived it. We introduced the product as a service, moving beyond hourly development work. This shift came from one simple belief: our role was to help clients discover what is truly worth building.

By 2013, the product mindset was becoming more prevalent, influenced by thought leaders like Roman Pichler, who introduced the role of the Product Owner in agile environments. Pichler’s teachings on maximizing business value, not just managing backlogs, became the cornerstone of how we approached product development.A great product isn’t just one that your customers love; it’s one that also drives tangible value for your business.

The reality of the market: when product thinking became a buzzword

For years, from 2013 to 2019, everything seemed to be on the right track. We were making the right moves, bringing in new roles like product strategists to help transform our software services into real product-building capabilities. But as the market evolved, the true nature of product thinking became diluted. Everyone started claiming to be “product-driven,” even if they had no structure, no experience, or no real understanding of what that meant.

We had processes, we had roles, but something wasn’t working. Despite all the right components, clients began to question the value we were offering.

That’s when things started to unravel. We had processes, we had roles, but something wasn’t working. Despite all the right components, clients began to question the value we were offering. “I feel like you’re more focused on lecturing me than listening,” said one client. ​​Another pointed out, “I don’t need workshops, I need solutions.” That was the turning point for us, as the quality of our services and client feedback have always been the ultimate measure of our work.

The crisis moment: product strategists and the build trap

As the market caught up, client payment habits started to shift, signaling new challenges. The questions became uncomfortable, and not just for us, for the whole industry. We started to realize that, despite having product strategists and designers, we were still missing the mark. We had locked our product teams in a “glass bubble,” separated from developers and the business side, yet they were supposed to deliver value to clients. We were measuring success not by the value delivered to the client or the business, but by metrics focused solely on the product itself—like the number of workshops, experiments, sophisticated canvases, or other internal outputs.

When we started reflecting on our situation, we saw the larger pattern: many companies, including ours, had fallen into the trap of focusing on outputs rather than outcomes. We were measuring success by the number of workshops, not by the value those releases brought to the client or business. We were caught in the “build trap” – a term coined by Melissa Perri in her book Escaping the Build Trap, which refers to delivering functionality without considering its real business impact.

The discovery: a product isn’t just a set of features

We were missing something critical: value. We had tools, processes, and rituals in place, but we didn’t have people who truly understood value from both a client and business perspective. We realized we needed to move away from a siloed approach, where product, business, and IT teams worked in isolation—and also educate our clients to ensure their environments don’t operate in this way. If we wanted to create truly valuable products, we needed to blend these perspectives.

We needed business-minded people embedded in product teams.\ It’s not enough to create a product your customers love; the product must also work for your business. We needed people who could go beyond the confines of the product itself and engage with the broader business environment in which the product operates. That’s when we made a key shift – we started integrating business leaders and financial perspectives directly into product teams. Every decision was now tied to company-wide goals, including revenue objectives and long-term strategy, rather than being limited to individual product outcomes.

You might be also interested in the article:

CTO as a Service solves the problems of a US digital product company

The importance of responsibility: creating a culture of accountability

We slowly began to realize that true product ownership doesn’t just reside in the product manager or designer. It’s a shared responsibility, ingrained in every role, from developers to business leaders. At Boldare, we needed to foster an environment where every team member could take ownership of the product, understand its financial implications, and work together to create real business value. A product is not just a department, it’s a way of thinking within the whole company.

We started integrating business ambassadors into our product teams – individuals who had a deep understanding of business strategy and could help steer product decisions based on market realities. This also meant providing our product teams not only with direct access to sales, client feedback, and financial data, but also with clear goals, meaningful metrics, and the knowledge necessary to drive impactful decisions. If we didn’t know how our products were impacting the business, we couldn’t create value – it was that simple.

You might be also interested in the article:

We are setting the benchmark: Boldare's Service Standards in a nutshell

The shift to interdisciplinary, inter-business teams

This shift in responsibility extended to how we worked as teams. We broke down the traditional silos between business, IT, and product. Instead of treating the product as a separate department or a “translator” between business and IT, we embedded business knowledge into every team. Developers, designers, and product managers now worked side by side with business leaders who understood the market, financials, and client needs.

Reshaping structure and responsibility

To drive alignment between product development and business goals, we restructured our approach from a specialization-based model to a purpose-driven, business-oriented one. This transformation went beyond just tweaking processes—it was about redefining roles and responsibilities across the organization.

We introduced Product Launchers—senior developers and designers who not only executed tasks but also played a crucial role in shaping product strategy. At Boldare, everyone on the team has skin in the game. It’s not just about understanding the purpose behind our work—it’s about taking ownership of the business outcomes. This approach eliminates any “bench time” mentality: if there’s no product to develop, team members actively seek roles within the organization or move on.

Our “no sales team” philosophy shifted the responsibility for business growth to entire business units. Leaders, teams, and even developers and designers were now directly accountable for results, including sales and client satisfaction. This required cross-functional teams that weren’t just interdisciplinary (development, design, product management) but inter-business, with members who understood the client’s business model, revenue streams, and strategic objectives.

To ensure this alignment, we embedded business-savvy leaders—like Business Unit leaders or myself—into product development processes. These leaders worked alongside Product Designers, UX Strategists, and consultants, bringing a grounded understanding of the market and its impact on careers, earnings, and long-term success.

Metrics that matter: from outputs to outcomes

Our shift in structure came with a transformation in how we measured success. We moved away from traditional output-focused metrics like the number of features shipped or sprints completed. Instead, we focused on metrics that reflected real business impact, both for us and our clients.

Key metrics now included:

• Revenue growth and segment performance, rather than just feature completion.
• Strategic goal achievement over sprint completion.
• Customer retention and the ability to drive long-term value.

This shift not only aligned our work with client and business goals but also created a culture of accountability and impact.

You might be also interested in the article:

Digital Product Launch Strategy that Effectively Attracts New Clients

A Two-Way Street of Learning

Finally, we committed to a two-way exchange of knowledge and responsibility. Business Unit leaders and teams became deeply involved in roadmaps, while developers and designers engaged directly with client feedback and business outcomes. This approach provided a holistic understanding of both the technical and business landscapes, enabling everyone to contribute meaningfully to strategic decisions.

The need for real business knowledge

One of the key lessons we learned was that product managers and team members must have a solid understanding of business. Without this knowledge, it’s impossible to make the right decisions or properly assess the risks and rewards of a product. This meant hiring people who had experience making tough business decisions – people who knew what it was like to lose money and feel the consequences of their decisions.

We started to wonder how well our product teams truly understand the real business impact of their work. Do they realize how the features they build affect the company’s financial results? Knowledge about costs, margins, and profits isn’t just the finance team’s responsibility — it’s the foundation for building products that deliver real value, not just meet user expectations.

In this context, it’s crucial to regularly ask ourselves and the team questions that help connect technical decisions with business consequences:

• Do people in product roles have experience running a business or have they ever faced a real failure?
• Do the people designing or building the product understand the cost structure and margins of what they are creating?
• Do they check how much has been sold every month?
• Does anyone on the team understand the financial risks associated with missing this functionality?
• Do developers and designers know which part of the product generates the most revenue or cost?
• Has the team ever participated in an analysis of abandoned customers or declining sales?
• Has the product/development team ever had the opportunity to ask a client: “Why didn’t you pay?” if you’re providing a product-building service for a client?
• Do we talk about changes in the market or competition when planning sprints?
• Can we connect a specific feature to a specific business outcome?
• If the product doesn’t generate money, does the product management team know that they will be involved in layoffs?
• Does your job/promotion depend on the financial outcome of the product?

These questions are not just a checklist – they represent a shift in mindset, a culture of accountability where product teams take responsibility for both the impact their product has on users and the business’s success. If your team isn’t asking these questions and connecting their work to the financial health of the company, it’s worth considering how this might limit your product’s real potential.

Final thoughts: responsibility, growth, and building the right environment

Looking back at the lessons we’ve learned, one thing is clear: we are all responsible for creating a product-driven environment. It’s not just the product managers or designers – it’s everyone in the company, from business leaders to developers. We all need to be involved in the product’s success, and we all need to take responsibility for ensuring that the product delivers real value.

If we’re not willing to build this environment – one where responsibility, business knowledge, and value creation are at the core – then we need to ask ourselves if we should continue down this path. The product will never thrive if it’s treated as just a department or a set of features. It must live and breathe within the entire organization, with everyone taking ownership of its success.

For those interested in diving deeper into the principles and strategies that informed our approach, we recommend the following resources:

• Roman Pichler, Agile Product Management with Scrum: A foundational guide for understanding how to effectively manage products in agile environments.
• Marty Cagan, Inspired, Empowered, Loved, Transformed: A series of essential works on building products that customers love and aligning teams with business viability.
• Melissa Perri, Escaping the Build Trap: How Effective Product Management Creates Real Value: A must-read on breaking free from delivering features for the sake of it and focusing on delivering true business value.
• Ben Horowitz, Good Product Manager/Bad Product Manager: A classic essay that highlights the differences between effective and ineffective product management practices.