July 29, 2019
The freedom of “Scope Last”
If you think of yourself as someone who executes the activities of his or her craft, you are placing an artificial limitation on your ability to serve your clients in a mutually profitable way.
Let’s say Alice is an excellent Rails developer. If she thinks of herself as “someone who builds amazing Rails apps” then the cost that she incurs delivering her service is a function of how much Rails work a given client needs done.
If on the other hand, Alice thinks of herself as “someone who knows how to build amazing Rails apps” then she has way WAY more flexibility in setting her costs.
For example, Bob comes to Alice and says, “I need a Rails app built. Carol told me that you’re amazing. We should talk.” Great! Alice sets up a call with Bob. The speak and Bob describes his situation.
Depending on Bob’s unique combination of available resources, time constraints, risk tolerance, desired outcomes, and a slew of other factors, Alice might rightly recommended any of a dozen or more options in a proposal.
Here are just three potential “Bob scenarios” each with three options that Alice might offer to help Bob reach his desired outcome within his constraints:
Bob has a low budget, lots of time, and would enjoy learning Rails
- Give Bob a 1-day crash course in how to build Rails apps
- Set up a dev environment for Bob and publish a starter project on Heroku
- Coach Bob through the development as he builds the app himself
Bob has a moderate budget, not a lot of time, and has access to a junior Rails dev that is inexpensive but is slow and does mediocre work
- Give the junior dev a 1-day crash course in how to build Rails apps
- Design the foundational architecture for the Rails app. Make all the key technology choices. Set up a development process and workflow for the junior dev.
- Work with Bob to wireframe the app, prioritize the feature list, and provide weekly sanity checks as the junior dev builds each feature.
Bob has a large budget, a looming deadline, and a few non-Rails web developers who are pretty busy with marketing initiatives
- Suggest Bob hand off the marketing work to some lower-cost contractors to free up the web team for the more important Rails work. Design the foundational architecture for the Rails app. Make all the key technology choices. Set up a development process and workflow for the internal web team.
- Provide project oversight and mentorship to the team as the build progresses. Research any unforeseen technology challenges and make recommendations based on your findings. Review pull requests and reject or approve as needed. Use rejections as learning opportunities to skill build the dev who sent the pull request.
- If Bob can’t use his internal web team, propose a soup-to-nuts project where you handle everything from concept to design to development to testing to beta to launch. If you can’t do all this yourself, assemble a small cross-functional team of your colleagues to get it done.
I could go on all night but I’ll stop there.
Here’s the thing...
If you stop defining yourself by the activities that you undertake on behalf of your clients and start thinking more broadly about how to package and sell your expertise, you’ll have loads of freedom when it comes time to pick a scope for a given price.
Value first. Price second. Cost (i.e., scope) last.
Yours,
—J