Outsourcing for Product Teams @10Pines

A couple of months ago, I read a post by two thought leaders I follow: Marty Cagan and Joshua Kerievsky. The post, titled "The Product Model in Outsourcing", explores how outsourcing can align with the Product Model and provides valuable suggestions on how to make it work effectively.

At 10Pines, we strongly believe in the kind of Product Teams that Marty describes and, since we do outsourcing, the post resonated deeply with me. As I read through it, I felt a strong connection to how we deliver our services and build software. I believe this is precisely what we have been doing since we started 15 years ago: providing exceptional software developers who help our clients achieve their desired outcomes by thoroughly understanding their needs and working collaboratively to reach them.

In this post, I will explain Product Teams in the Product Model and provide key reasons why 10Pines is an ideal partner for companies that work this way and need to outsource their developers.

First, what is a Product Team?

Here's my definition of a Product Team: it consists of a cross-functional group of empowered individuals led by a product trio. This team is involved in all phases of development, learning in short cycles, and prioritizing outcomes over output. Let’s break down this definition.

A Product Team is composed of individuals with all the necessary skills to deliver each step on the journey toward building the product. The team shares responsibility for the outputs and outcomes. They work together to create the best solutions. Each member is empowered to leverage their expertise, whether they're Product Managers, Product Designers, Graphic Designers, Software Developers, or Testers. They are a united team of missionaries. They solve user problems in ways that also benefit the organization.

Avoid a critical anti-pattern: the divide between Business and IT. Business is responsible for outcomes, and IT for outputs. As Jeff Patton points out, this separation undermines the product mindset.

Product Teams are led by a Product Trio. A product must be valuable, usable, feasible and viable to succeed. It must solve user and customer problems, be easy to use and be viable to the organization. Your leadership team needs a mix of product management, UX, and technical skills to achieve this. This combination is crucial for creating great products. These leaders must collaborate closely on decisions which often involve trade-offs, like accepting technical debt to meet a deadline.

Product Teams are involved in every phase of software development. They watch for opportunities in the problem space. They prioritize based on the organization's vision and strategy. They find, improve, and plan the best experiments. They discard them when needed, before delivering the solutions.

Many organizations have a common anti-pattern: they exclude software developers from the discovery phase. This often leads to decisions made without knowing their feasibility and it forces developers to implement solutions based on already finalized designs. When this happens, we lose valuable insights and potential improvements.

Product Teams learn in short cycles. The faster a team moves from spotting an opportunity to deploying a solution and measuring its impact, the more they can learn and improve business outcomes. This approach aligns with Eric Ries's Lean Startup, proposed years ago. Ries used the term "Minimum Viable Product" (MVP). It may not have been the best name to encourage rapid iterations. Terms like "Next Best Test", "Rapid Assumption Testing", or "Experiment" can better highlight the value of quick learning cycles.

Last but not least, these teams focus on outcomes. They view output as the bare minimum to achieve their goal. They always ask, "What's the best way to reach this outcome?" They conduct frequent inspections and make adjustments to their processes to keep them lightweight. They aim for a "barely sufficient" methodology, as Jim Highsmith suggested. In the discovery phase, they define how to measure their experiments. They do this by identifying the relevant product metrics. Afterward, they evaluate these metrics to inform their next steps.

Is it possible to build a Product Team with outsourced developers?

Absolutely! At 10Pines, our culture and methodology perfectly align with the principles of effective Product Teams. Our vision has always been to build honest long-term relationships that allow us to contribute our technical expertise toward achieving our client's objectives. How do we do this? In short, we create a collaborative environment that makes all the elements of a successful Product Team possible.

More specifically:

• We ensure that all members, including both business stakeholders and 10Pines developers, feel like they are part of the same team, united by shared goals.
• We promote full transparency, where information flows freely from all sides.
• We actively involve all team members in the Discovery phase, ensuring that 10Pines developers are integral participants from the very start.

Now, let me dive deeper into the specific practices we follow to cultivate these relationships and why this makes us a perfect fit for companies looking to embrace the Product Model.

We use Time & Material contracts

At 10Pines, we use Time & Material contracts because we believe that a contract should foster collaboration and empower the team to work together seamlessly. All parties involved should feel comfortable with the agreed terms, and the contract should provide the flexibility needed to achieve the desired objectives. It should also cultivate an environment of trust, where all relevant information —like objectives, metrics, and progress— is openly shared.

The clearest anti-pattern to this approach is the fixed scope, fixed time contract. These contracts hinder a team's ability to learn, run experiments, and benefit from iterative and incremental development. You might run Sprints, but what's the point if you can't adapt based on the feedback you receive? These rigid contracts force developers to focus solely on output, stripping away the opportunity to engage in Discovery. Moreover, they're often signed with limited information, without proper discovery, and without adequately assessing risks. This approach can lead to a multitude of issues down the line.

Our software developers are passionate about Discovery

Once we’ve established the right conditions for collaboration, we emphasize the importance of involving the entire team in the Discovery process, including software developers. Often, clients come to us with ideas or a predefined backlog, and our recommendation is to start with Product Discovery Workshops. As my colleague Jorge Silva describes in this post, we conduct these workshops as part of the sales process to ensure we’re building the right product from the start.

It’s also common for our lead developers to encourage the rest of the team to engage more deeply in Discovery activities—learning from users, participating in interviews, visiting the environments where the product is used, and understanding the value hypothesis along with the metrics for success. Designing and developing with this level of insight transforms the approach, sparking a mindset that’s fundamentally different from simply coding based on backlog tickets.

We are Agile

We are Agile. Embracing Agile is crucial to supporting the way we work. Let me clarify what I mean by Agile in this context:

• Working iteratively and incrementally
• Involving business users early and often
• Focusing on small, manageable increments
• Enhancing communication at all levels
• Continuously inspecting and adapting our approach

Our teams operate this way because we believe it’s essential to create an environment where our clients feel comfortable opening up and sharing all the necessary information. Agile practices foster the transparency and flexibility needed to truly collaborate and align with our client’s goals.

We are transparent

Trust is essential for building true product teams where individuals from different companies work seamlessly together, trust is essential. Everyone on the team must feel that they share the same objectives—successes should be celebrated by both our clients and us, just as challenges should be faced together. Building this trust requires an environment of complete transparency on both sides, supported by the flexible contract model I mentioned earlier.

From our side, our software developers "open the kitchen," providing the entire team with visibility into the challenges, difficulties, impediments, and decisions at hand. We ensure transparency in the codebase, tools, meetings—everything. That's why practices like pair programming and openly discussing detected issues are a natural part of our process. Our goal is to ensure that even non-technical stakeholders understand everything that’s happening.

Our approach to invoicing is equally transparent. At the end of each month, we provide a detailed timesheet that clearly outlines what we’ve worked on, day by day. This level of detail ties back to our Agile practices—working in iterations, delivering small increments, and continuously gathering feedback—all of which create the kind of transparency our clients truly value.

What's important to note is that this way of working comes naturally to us because it’s embedded in 10Pines’ culture. For instance, our timesheet data is directly pulled from the same application our developers use to log their hours and process their paychecks—there’s no extra effort involved. Transparency isn’t an add-on; it’s simply how we operate.

We are good software developers

We are good software developers. I know that might sound a bit bold, but what I can say with certainty is that we are passionate about software development and always striving to improve. Here are a few ways we make that happen:

• First, we carefully select talented software developers who genuinely enjoy designing, practice Test-Driven Development, and are committed to continuous learning.
• We dedicate 10% of our time to studying and growth. Yes, 10Pines actually pays us to explore new programming languages, read, and code just for fun.
• Our team is highly disciplined. We do a lot of pair programming, rigorous code reviews, and adhere to established standards. We favor continuous integration and automate processes whenever possible.

But why is having skilled software developers so crucial for building great Product Teams? To earn trust, it's not enough to be honest and transparent; you also have to prove that you're capable of delivering high-quality work. Our developers play pivotal roles in our client's projects, making architectural decisions and actively participating in product trio discussions. Their expertise and dedication help create a solid foundation for trust and collaboration.

Our quality pillars support these types of teams

Our quality pillars are: 

• Technical excellence, reflected in the technology, methodology and results of the projects we develop, supported by the communities that promote them. This pillar impacts on the quality of the software we develop, which is really important in the delivery phase because it has an effect on the final users and on the sustainability of the product.
• Sincere and long-term relationships with our customers, shown in our commitment to their objectives and the added value brought by the solutions we create. Our commitment to our client's objectives and the added value we provide through our solutions are at the heart of this pillar. We know that building strong relationships goes beyond simply delivering features from a specification. We dig deeper to understand our client's goals and strive to reach them in the most effective and efficient way possible.
• Human quality, based on open internal management, in equal shares of possibilities and responsibilities among all members and a strong focus on the team’s unity. This is the foundation upon which everything else is built. It’s rooted in our open internal management, where all team members share equal opportunities and responsibilities, and there's a strong focus on team unity. This pillar shapes not only the quality of our work but also the way we collaborate and build relationships, and ultimately, how we feel as a team.

These quality pillars are what enable us to support and empower Product Teams effectively. They ensure that we don't just focus on delivering functionality but also prioritize the overall value we bring to our clients, our people, and the products we create together.

Our culture supports these types of teams

At 10Pines, our culture is a natural fit for building and supporting high-performing Product Teams. We have a horizontal structure that empowers every employee to actively participate in the management of the company. We maintain open book management, ensuring that everyone has the information they need to make well-informed decisions. We embrace a culture of experimentation, constantly trying new approaches to refine our policies, adopt new tools, or make improvements within 10Pines.

This mindset directly influences how our developers work with our clients. They’re motivated to get involved, understand the client's objectives, and share their perspectives. One of the most common pieces of feedback we receive from clients is how much they value the commitment they sense from our team members. Our developers don’t just work on the projects—they strive to become integral parts of the teams, just as they are at 10Pines.

You can learn more about our culture here.

Conclusion

At 10Pines, we believe that great products come from great Product Teams—teams that are laser-focused on driving both product and business impact while continually experimenting and learning in pursuit of these goals.

Building these types of teams with outsourced developers requires more than just technical skills; it demands a true partnership rooted in trust, collaboration, and a shared commitment to achieving meaningful outcomes. It means creating an environment where every team member feels empowered to contribute, innovate, and align their efforts with the broader vision.

This is precisely what we have accomplished over the past 15 years. Our culture, Agile mindset, and quality pillars are intentionally crafted to foster the conditions that these teams need to thrive. We don't just see ourselves as software developers—we see ourselves as partners in our client’s journeys, dedicated to understanding their challenges, sharing their vision, and working side by side to build products that deliver real, lasting impact.

Our approach goes beyond simply delivering functionality; it's about creating value, inspiring trust, and ensuring that every decision we make contributes to our client’s success. By aligning ourselves with the principles of the Product Model and cultivating a culture that encourages openness, experimentation, and continuous improvement, we make sure that we're not just building software—we're building successful, high-impact partnerships that help our clients achieve their goals.

Interested in our services? Let’s chat! Our reviews? See them in Clutch!