Marty Cagan’s recent comments on Software Agencies came as a bit of a surprise, but I was pleased to see such insights from someone so influential in our industry. Marty has done a great job capturing the reality, and his perspective prompted me to delve deeper into the topic, drawing on my decade of experience representing a Software Agency.
Marty provided a “fair enough” assessment of Software Agencies. If you haven’t read his piece, I highly recommend doing so before diving into my comment.
https://www.svpg.com/the-product-model-in-outsourcing/
My experience extends beyond co-creating an agency—I’ve also collaborated with other agencies across numerous projects. While Marty focused on the challenges from a client’s perspective, I want to shed light on the agency’s side and explore why so much money is wasted on outsourcing.
I'm sharing my thoughts because we (Appunite) are on a mission to transform how software houses operate. While we are halfway there, I wanted to highlight the challenges we've identified, the progress we've made, and what's next.
Specification to make sure work is delivered correctly
In most cases, Clients approach agencies with a specific solution in mind. Agencies, in turn, are eager to play that game. Even if a Client doesn’t have a specific solution, they often frame the conversation as if there’s a one-size-fits-all answer that can be estimated, specified, and delivered on time.
Agencies generally prefer scoped work, and the market reinforces this preference. The dilemma then becomes: should we invest time in gaining more context or craft an offer similar to what other agencies provide?
Sales teams often rush to provide estimates because it’s a key argument in client discussions. Developers, on the other hand, hesitate to commit until they fully understand what needs to be built. Best case scenario, this disconnect leads to workshops—not for discovering the problem but for- again, specifying the solution. Unfortunately, this is the path many agencies take when clients don’t have detailed specifications.
We’ve been there too. A few years ago, we wouldn’t involve developers in the conversation until the designs were finalized. The design process was a separate entity, occurring between our business representatives, the Client, and the designer. Once the design was approved, we’d assemble the team. Looking back, I feel a bit of shame—but it was a learning experience that taught us how not to do things.
High demand for developers has significantly impacted the sales process
Having a solution in mind, Clients seek the best quality-time-price ratio. The window for exploring conversations beyond the standard scope—such as providing specifications, team size, lead time, and cost—is often very short, especially when other agencies are quick to offer these details.
This issue isn’t just the Client’s fault. It’s a consequence of how agencies grew, especially when the demand for developers was high. Some agencies didn’t feel the need to change. Recently, I witnessed a panel discussion where software house founders openly stated they didn’t want to get involved in product and business—they just wanted to deliver the software and move on. This mindset is prevalent, and it eats away at the industry.
Almost every agency talks about the impact they can have on Clients, but when you dig into the details, you find that everyone interprets “impact” differently. A good way to gauge this is to ask an agency how they define the success of their collaboration.
Agencies often focus solely on development competencies, missing the bigger picture
Buzzwords like MVP and POC are still thrown around. Many Clients believe that when they reach out to an external agency, they need to have all the exploration done, and a solid specification in hand. They think this ensures smooth onboarding and speeds up development, but that’s rarely true. Often, decisions aren’t documented, aren’t backed by research, and are more like a stakeholder’s wishlist. If Clients don’t have this ready, they expect it to be prepared before the collaboration starts.
Getting beyond coding is hard
I’ve seen that many agencies lack the competencies and skills to deliver value beyond coding. They lack product and design expertise and, most importantly, the right mindset for product development. This approach is widespread in software agencies and has impacted the entire industry. One of the biggest challenges in creating an outsourcing company capable of taking ownership of the problem is assembling the right team. Many developers don’t want to engage in deeper discussions; they prefer to focus strictly on the technology, expecting the “rest of the work” to be handled by non-technical people. Over the years, we’ve learned to identify such individuals, but the extent of their impact continues to polarize developers.
Software house as a place for product people
For product-oriented people, a software house isn’t usually the first choice. You’re more likely to find a project manager than a true product manager in such environments. Although the variety of projects can be tempting, being outside the Client’s organization makes it harder to have a significant influence.
So, if agencies can’t play the role of Product Manager, they fall back on being good at delivery. The problem is that even though they can deliver a solution, it often doesn’t address the root cause. The return on investment is rarely positive. In such situations, agencies may try to shift the blame onto the Client, claiming they delivered exactly what the Client wanted, on time. However, I don’t know a single Client who returns under these circumstances, even if the agency thinks they did a great job—they didn’t.
Product vs Client—who to serve
This dilemma is very real. An agency striving to make a meaningful impact must constantly balance between satisfying the Client who hired them and serving the users of the Client’s product. Unfortunately, not every client sees these as aligned goals. Challenging stakeholders might ultimately benefit the end-users, but it could also lead to the agency losing the contract. This tension often depends on how the agency defines its value. If sales take precedence over actual results, the agency may be more inclined to agree with whatever the stakeholders want to build, even if it’s not in the best interest of the users.
This dilemma is akin to the challenge faced within a product company, where one must choose between pleasing stakeholders and serving users. However, the twist here is that as an external agency, you’re always at risk of being cut off more easily. This is why some teams, fearing the loss of a client, may instinctively avoid raising critical issues.
Timesheets
Timesheets are still very much in play. Both Clients and agencies continue to rely on them. Clients appreciate the reassurance that the hours they’ve paid for are indeed being spent on their project. Meanwhile, agencies use timesheets as proof that the client is receiving what they’ve paid for. As I mentioned earlier, most collaborations operate on a time and material basis—a model designed to avoid ownership.
I recall a time when most projects were billed at a fixed price, but agencies soon realized that the carefully crafted scope would inevitably change during development (who would have thought, right?), leading to delays in delivery and even financial loss for them. To mitigate this, agencies adopted the time & material model. This approach allows them to take on less ownership and sidestep accountability, even at the delivery level. The only thing it truly guarantees is that the developer spent time working on the project.
There is still much that needs to change
The market has evolved in a positive way in that aspect, there are fewer projects per agency, which makes them rethink the way they operate. Many agencies have adapted their approach, but the industry as a whole still bears the mark of past practices. It’s challenging to distinguish between those agencies that genuinely understand the changes required to meet the realities of today’s product-building environment and those that merely use these ideas for marketing purposes.
While I agree that Clients need to rethink how they cooperate with agencies—how they search for partners, outsource technology, and so on—I believe there is even more for agencies to address if we are to see these changes take hold on a broader scale.
So what should the cooperation with a modern agency look like?
We've been testing different approaches, and while we can't yet say we've found the perfect solution, we have a good sense of what it might look like. We've already made progress in certain areas of our operations, while other parts are undergoing extensive testing with both existing and new clients. Some aspects remain aspirations that we're eager to pursue.
Tailored approach for immediate value delivery
We place great emphasis on how we initiate conversations with clients. Rather than relying on traditional sales presentations, we prioritize understanding the client's needs from the outset. While this might seem straightforward, transitioning the conversation from discussing solutions to exploring the underlying problem, context, and constraints is often challenging. At this stage, we focus on discovery rather than education, as we recognize that we don't yet have enough information to offer solutions confidently. The conversation becomes valuable when the client uncovers new insights or realizes we can deliver more value than initially expected.
We swiftly involve our experts to analyze the context gathered during the initial call, identifying areas where further exploration is needed. If we detect gaps in the client's understanding at the product level, we connect them directly with our Product Growth Manager. This marks the beginning of our consultation process, where we aim to provide value while deepening our understanding of the client's business.
We have moved away from conducting large workshops that clients pay for, as we've found that the value delivered in these sessions is often insufficient. Instead, we meticulously document the problem, context, and constraints—not the solution—ensuring that everyone involved stays aligned as the information evolves.
Our organization follows a mission-command approach. In simple terms, we define a mission for the team that outlines the problem, context, and constraints. The mission owner then prepares a backbrief, presenting a general solution approach to confirm the team's capability to deliver. This approach is integral to our sales process, where the goal of discovery is to craft the most accurate mission based on the client's needs.
Two key teams are involved at this stage, reflecting our organizational structure. The Sales team focuses on answering:
- Why are we building this?
- What impact will it have on the client's business?
Meanwhile, the Opex team (our internal term) ensures we understand:
- What do we need to build?
- How are we going to build it?
This collaboration forms the foundation of the offer we present to the client. Any gaps identified during discovery are noted in the mission as "known unknowns." When the client is ready to proceed, this mission serves as the handover document to the team forming phase, which I will elaborate on further.
Our process is continuously evolving. After every client interaction, regardless of whether we sign a contract, we assess how we could have better understood the client's problem. There's no rigid process dictating the number of conversations needed; instead, our curiosity drives us to understand as much as possible to define the best problem statement at that time.
Comprehensive product development expertise
Our teams forming process is focused on assembling the best possible team for the mission at hand. We ensure that the team has the capabilities to drive the mission forward and solve the problem. Over the years, we've learned that gaps in expertise can significantly slow progress or even halt it entirely. We've drawn from concepts in Inspired and Empowered, combining them with our experience to deliver beyond just code. While technology remains at our core, what others might call supporting roles are crucial to our approach.
It's worth noting that we also collaborate with clients who bring their own product managers, which is entirely fine with us. Our priority is ensuring we have the competencies needed to create a cross-functional team capable of addressing the problem.
Commitment to outcome ownership
Problem-solving is deeply ingrained in our culture. Even internal initiatives are regularly reviewed for outcomes. A significant milestone for us has been the intentional selection of our team members. As I mentioned earlier, some developers prefer to focus solely on delivery rather than continuous discovery. We don't hire those who set such boundaries. We expect everyone to understand the desired outcome and commit to achieving it. Everyone, including those in strictly technical roles, is evaluated based on the impact they have on our clients.
Iterative process guided by user feedback
We place great importance on clearly communicating the outputs we generate each week. We even have an internal channel, "what-we-shipped," where teams across various projects share their achievements. However, we emphasize that success isn't defined by the release itself—the release is just the beginning. We prioritize having direct access to users. We are constantly refining our user interview skills to improve. The common goal across our growth and service departments is to generate the most positive ROI cases for our clients, which is why we validate our work at the outcome level.
Seamless transition to internal teams
Many companies hesitate to outsource due to concerns about vendor lock-in or losing context when transitioning to an internal team. We understand that circumstances change, and there are times when having an internal team is more practical. We don't resist this shift. In fact, we have a history of assisting clients in recruiting internal teams and ensuring a smooth transition of knowledge, resources, and responsibilities.
Value-based pricing
We are currently experimenting with value-based pricing models. With a history of taking ownership through joint ventures with our clients, we've even invested in products we believe have potential, allowing us to take ownership at a deeper level. Our ongoing experiments involve correlating the results we generate with the price our clients pay. We believe this approach represents the future, and while we're still learning, we're eager to explore this direction further.
Money-back guarantee
This is another experimental component of our system. As we move towards value-based pricing, we're also exploring ways to share risk with our clients. We want our teams to be goal-oriented and focused on delivering expected results. While we don't always have full control over achieving the goal, we're open to sharing the risk with our clients. We only commit to missions when we are confident in our ability to deliver. The general idea is that partnering with us increases the likelihood of success compared to going it alone. We're willing to take on greater risk and even offer a money-back guarantee if the desired result isn't delivered. While this isn't something we standardize yet, we're open to discussing it.
Summary
While there's still much to explore in our journey to build the service we've envisioned, we're not waiting for someone else to discover the way forward—we're taking the initiative and embracing the risks along the path. Although some aspects of our approach might seem familiar, we've already made significant changes to deliver greater value to our clients. If you're interested in being part of this journey, reach out to us. We're open-minded and ready to collaborate on crafting solutions that truly work for clients like you.
Let's create a lasting impact together.
If you're ready to work with a software agency that goes beyond just delivering code, and truly partners with you to solve your most pressing challenges, let's start a conversation.
