Fixed deliverable software contracts are guesses and almost always wrong.
This is why you should focus on outcomes and teams.
How many technology leaders have gone out looking for a software vendor somewhere in the world with an RFI or RFP asking for a fixed-scope contract to include a specific number of features, only to either be ultimately disappointed with the result or upsold dozens of change orders when reality sets in?
Fix-scope contracts are rewarded because they are black and white. They give the illusion of de-risking for the buyer. But they are almost always without alignment around the correct outcomes, quality, and norms of working, and have no way of accounting for the unknown unknowns that are guaranteed in every software development initiative.
Fix-scope software contracts are guesses.
In my 17 years in this industry, I have seen maybe one or two very specific products where the product owner knew exactly what their product should look like, what it should do, how it should respond, how much it would need to scale, where it should start, and possibly what features it would grow into... before a line of code was written.
The ones that did were extremely simple in functionality—like a one-trick pony. (It’s amazing if you can find something like this that hasn’t already been done.)
99.99% of software, apps, and digital products are large guesses at the start.
Hypotheses on features, use cases, integration needs, deployment scenarios, data management, device support, mission-critical starting points, and level of value to the user, etc.
There are some exceptions to this.
For example, WordPress websites based on a template, or a platform reseller that does simple integrations to make their product fit the user’s minor adjusted needs.
This is not what I’m referring to.
I’m talking about innovative, potentially disruptive, or even competitive solutions in a crowded "me too" market/user space, where everything seems obvious, but you want to catch up and surpass your competitors or the existing solutions in the market. This is always more complex than you think.
Building your own digital products is about addressing a unique set of challenges or needs.
By their very nature, this means there are many unknown unknowns.
This could be as simple as where to have a modal open, or it could be about how to handle sockets for real-time collaboration with hundreds of users simultaneously in an interactive canvas while prompting a privately hosted LLM in your own container for privacy and security, all while training your custom model on top of the foundational model so that you can create dynamic, personalized experiences for your users that meet their unique needs instead of generic ones.
Sure, the second scenario seems like a complex one, but if the modal doesn’t open in the right place at the right time, then the user may never experience that dynamic feature set.
But the contract said…
So, do we put in the contract that your app will include all these features, plus all the default app functionality, plus the color of the button that will get their attention enough to open that modal to access the LLM model that we plan to train but have not yet trained so that we can achieve the dream state we have in your mind?
No, of course not.
Instead, contract a team with a shared set of goals.
Why this, why now, for whom, and with what outcome?
We set constraints and identify what is driving those constraints: budget, a fixed date (year-end, conference, large project kickoff), team size and skills, dependencies, infrastructure, etc.
Then we align the team. This is the most important part.
What are WE here for?
What are each of our roles?
Why are these skills needed?
And how might this change over time?
Finally, what will success look like?
It is not merely to launch. While this is a feat in itself, it’s not the goal.
The goal is engaged and deliver value to users who are better off because what you built is part of their lives.
Be mindful of assuming that a PRD (Product Requirements Document) for an RFI/RFP is going to get you to that state.
Assume you know very little, and then contract, hire, or acquire a team that is rowing in the same direction to prioritize what matters most, when, and who is flexible enough to learn, collaborate, communicate, and adapt as they move forward within those constraints.
Agree to a better contract.
When looking to contract software there are a few options.
Staff Augmentation
Find a company that can resource you with individual team members and you build a team. This team will need to be managed. Either self-managed or by the product manager. And they should have access to resources and other stakeholders to make sure they are not operating in isolation. Consider, UI Design, Testing, Front End development, API and Data architecture, or full stack.
These contracts are often billed on the hour or on a retainer. They can also be staffed into FTE over time with a management and/or finders fee.Product Teams (Squads)
The benefit of a squad approach is often their ability to work together well already.
A product team will include all of the roles mentioned above or can blend with those roles if they already exist in the organization. A Product Team agency will handle staffing all roles, setting team norms, integrating with internal and external stakeholders, and managing constant communication between everyone.
These contracts tend to be time and duration. A weekly, sprint-by-sprint, or monthly burn rate, with the constraint of duration on the project.
Check out Crema
Crema is a design and technology consultancy. For 15 years we’ve been fully integrating product teams with our clients to design and build technology and technology teams. Crema aligns leadership, explores possibilities, prototypes ideas, validates with users, designs scalable systems, and builds software solutions that help companies make money, save money, and grow fast!