This is a complete guide to building your product by enlisting help from a development shop.
In this in-depth guide you’ll learn:
- Is a development shop right for your business
- What to watch out for when working with development shops
- How to have success with development shops
- Plus more
If you’re ready to answer whether a development shop is right for your business, this guide is for you.
Let’s dive right in.
Is a Development Shop Right for You?
We’re going to start by answering a simple question: Is using a development shop right for you and your project?
But before we get to that,we need to answer why entrepreneurs hire development shops in the first place.
- Founders are often attracted to development shops in the same way we’re attracted to mechanics to fix our cars: we don’t know how to perform a specific task and they offer us a team of professionals who can execute on our behalf…for a price.
- Speaking of price, development shops are expensive. Because of this, a poor outcome can sink a concept simply due to the cash outlays required to arrive at that poor outcome.
- Finally, not all development shops are created equal. Just like the mechanic example we used earlier, your mileage may vary, and learning to pick the right firm for your project is a critical skill to arrive at asuccessful outcome.
Let’s begin with two basic definitions and assumptions.
First, at the stage where most people engage with a development shop, they are seeking to build the first version of their product, their Minimum Viable Product. To give yourself a reasonable shot at a successful engagement with a development shop, you’ll need to self-impose some limitations on the scope of what you ask them to build.
Second, we need to define what a development shop actually is. The easiest way to understand a development shop is that they are a firm that provides its clients with:
1. A cross-functional team
This means they have all of the necessary skills on their team to build projects including language and framework expertise.
2. A co-located team
This means that their team is located in the same space which makes communications easier and faster.
In the age of COVID, this looks like a shared virtual space, but these teams have done a pretty good job so far of making this transition work.
3. Project Management
Managing software projects is very different from managing other kinds of projects. For that reason, it’s best to have someone with experience managing the project on your behalf.
Any development shop worth their salt will employ qualified project managers to help keep the gears spinning smoothly on your project.
In addition to these benefits, development shops are beginning to offer consulting and advisory services to clients, too.
These services can cut both ways: On the one hand, their expertise and experience can be invaluable to early-stage founders. On the other hand, we’ve seen development shops deploy these services as little more than sales tools wrapped in the veneer of “trusted advisors.”
Ok, now that we have the foundation laid, we need to talk about whether or not development shops are a good fit for you and your project.
To start, let’s talk about how to know if a development shop is a good fit for your project:
1. You’re well-capitalized
There’s no getting around it: development shops are expensive.
You need to be sure that you have the money to not only build the product but also to maintain it after launch and fund the first phase of your business—finding product-market fit before you run out of money.
2. You’re busy
In some ways, one of the big benefits of development shops is that they handle much of the day-to-day requirements of developing a software product for you.
If you’ve got another business to run, a day job, or maybe you’re building your product to add to an existing business, a development shop can really help take some of the time and energy requirements off your shoulders.
3. You’re new to software products.
Software is tricky. We’ve seen seasoned entrepreneurs brought to their knees by the rigors of building and growing software products and businesses. Development shops have the expertise to help guide you and your product during some of the most critical early-stage decisions and strategies.
Right, so we know why development shops may be a good fit for your product or company, but what about reasons why they aren’t good fits?
In addition to the above being untrue for you and your team, here are a few reasons why it may not be a good time to engage a development shop.
1. You’re not ready to manage people
It’s true that development shops handle a lot of the day-to-day building of a software product for you, but that does not mean that you can take your eye off the ball, so to speak.
Development shops are often distracted by many clients at once and, if you abdicate your responsibility for ensuring that the shop you’ve hired is holding up their end of the deal, you’re in for a world of frustration and disappointment.
2. You’re not prepared to be a founder
Development shops build software products. They do not cast a vision for your company, develop business, hire talent, etc.
As a founder, you will still have many, many responsibilities to manage when it comes to building your company and setting it up for success. Building a product is just one part of building a business.
3. You haven’t validated your concept
Bringing a half-baked concept to a development shop is a waste of everyone’s time and a lot of your money. Development shops are not responsible for ensuring that your concept is validated.
Some of the more scrupulous development shops we’ve worked with will reject potential clients if they think they haven’t done the work to validate their concepts appropriately. However, these are exceptions to the rule. In most cases, development shops are happy to take your money regardless.
The responsibility to make sure you’re building a solution to a problem worth solving is yours and yours alone.
A Roadmap for Development Shop Success
As you’ve probably already begun to understand, there are two main ingredients for successful development shop projects:
- Active (and appropriate) involvement from stakeholders
- Insistence on scoping and agreeing to an MVP level of work
The good news is that, if your project is a good candidate for a development shop, there are a few steps you can take before and during the engagement to have a successful outcome.
Validate Before You Buy
Many founders treat their development shop partners as consultants. In fact, as we’ve discussed previously, some development shops actually sell consulting services.
In some cases, these can be really valuable, but usually only as the consulting deliverable pertains to technical elements of the project. When it comes to business strategy and monetization, steer clear of development shop consulting engagements.
There are just too many conflicts of interest for these engagements to be helpful.
The alternative is to develop these elements of your product’s business case yourself. You can refer to our, “Avoiding the Software Sinkhole” series for more details, but here’s the gist of what you need to do to validate your product before you go signing contracts with a development shop.
Conduct problem interviews to find out if you’ve actually identified a problem worth solving.
Test your riskiest assumptions with prototypes. Prototyping is a cheap and effective way to make sure that what you’re building is easy to navigate and understand.
Deliver a Concierge MVP, a version of your product that you deliver by hand. A Concierge MVP can allow you to actually deliver value, manually, and begin gaining a better understanding of how customers see your product and where the value actually lives.
Write an Actual Business Plan
Yes, technology can make many things faster and easier, but running a business is still…running a business. You need to document your vision, your strategy, and your tactics so that employees, co-founders, investors, and yes, your development shop of choice can understand how your product fits into your business.
Vision
This tells the reader why your business exists, the problem you’re trying to solve, and how the product you’re building can solve that problem in a way that customers will be willing to trade something of value to access.
Strategy
Anyone who reads your business plan should have a good idea of how you plan to launch and scale your business within a reasonable time frame. This includes product development, marketing, and sales.
Monetization
It could be argued that this fits into strategy, but we wanted to break it out because of how important it is. Every single person you meet will be interested in the answer to two questions: can this product make money and how do you plan to do that?
Take an Active Role in Scoping
Your first project with a development shop will be a doozy. To keep it from turning into a nightmare, you should take a few steps to ensure that things are scoped appropriately.
Stick to the MVP model
Your first project should create the smallest version of your product that delivers value to your customer and that’s it. No bells, no whistles…just value in the smallest possible package.
Lookout for Scrum Fall
Development shops are notorious for touting their Agile bonafide, then proceeding to scope huge projects that get broken into “sprints.”
Trust us when we tell you that this is NOT Scrum or anything close to Agile. In fact, it’s a problematic scoping and project management technique often referred to as “Scrum-Fall,” denoting its unholy mashup of Scrum and Waterfall development methods.
Listen to Your development Shop Partners
Development shops have deep experience and expertise. You should absolutely listen to their advice and input on your project. They will certainly see and point out things that you would never have considered and that will make your project and product all the better for it.
Treat Your Development Shop as a Part of Your Team
Yes, you’re outsourcing, but this is a little different than hiring an HVAC contractor or a business consultant.
Development shops are building your product. For this reason, it’s essential that you treat them as a part of your team.
Setting regular meetings with your point-of-contact
This is usually a project manager. You need to be in regular contact with this person and utilize all of the tools you are given access to in order to monitor progress.
Ask lots of questions, insist on getting satisfactory answers, and come prepared for all of your meetings. This shows your development shop partner that you are engaged and respect their time.
Giving and receiving honest feedback
Software development is complex and complicated. This makes adjusting your working, decision making, and communications styles frequently a necessary task.
You should give regular feedback to your development shop partners and, just as importantly, ask for feedback about how you can do all of these things better.
Be patient and understanding
Development shop projects can be frustrating for all of the reasons we’ve covered in the past few blog posts. But, it’s important to remember that sometimes it’s far more productive to extend patience and understanding when things get complicated than it is to bring the hammer down.
By collaborating and problem-solving, you’ll give your project and product the best chance of success and give your development partners a good reason to go the extra mile when you need them to.
Development Shop Meltdowns
Why Development Shop Projects Go Wrong and How You Can Keep It From Happening to Your Project
Development shops offer first-time and non-technical founders the cross-functional, co-located team they need to build their product and deep technical expertise to help guide these founders in the best practices for software development.
Cautious because, in our experiences, a “best-case scenario” can be hard to come by.
Today we’re going to talk about why development shop projects go wrong and how you can avoid a development shop meltdown.
Poor Expectation Management
Most development shop revenues are tied to the billable hour. They do an hour of work (or some fraction thereof) and you get billed for it, usually in bi-weekly or monthly billing cycles.
What this creates is an incentive to book and bill more volume as opposed to more quality. More billable hours mean more revenue for the development shop.
Unfortunately, what this can mean for founders is that, if they allow the development shop to scope the project with little input from them, what they can end up with is a six-plus figure product that, in our experiences, will suffer from its own complexity at launch and end up costing even more money down the line.
Founders often fall victim to this scenario because the scope just sounds so exciting! Who doesn’t want the full-featured, fully realized product at the end of their engagement?
However, if you want to avoid signing on for a massive initial build and suffering the consequences of fixing that big, complex product almost as soon as (if not before) it launches, you’ll do yourself a favor and insist on limiting the scope to the true spirit of an MVP.
The Billable Hour
As we discussed in the previous section, development shops usually use a billable hour model to generate revenue. We’ve covered the reasons why this can incentivize unwise project scoping decisions, but now we want to address how this model can slowly bleed you dry.
Remember how we said the billable hour can look really attractive at first? You’re only paying for what you use, right? Well, yes. And that’s the problem.
You see, this is only a benefit if the work being done is done correctly and without flaw the first time. However, when features begin to break and one change to the code base creates a hell-storm of downstream problems, you quickly begin to realize that the billable hour isn’t going to be your friend.
In fact, you’ll soon realize that it is your enemy by its very nature.
Look, we know that billing and revenue is a big thorn in the side of everyone in the industry, clients and development shops alike. And we don’t presume to have easy answers to these issues.
What we can say is that the billable hour is serving no one well.
Alas, the billable hour probably isn’t going anywhere anytime soon, so here’s how to make it a frenemy instead of an enemy.
It’s easy, really: begin with a recommendation in the previous section and insist on a scope that builds a Minimum Viable Product.
Then, commit to being engaged with your project manager. Set regular meetings, ask LOTS of questions, and insist on getting satisfactory answers before you approve work.
In the end, the only way to counter the billable hour’s worst nature is to do more work to ensure that you’re deploying those hours as efficiently as possible.
Attention Deficit Development Shops
A nice way to wrap up both of the issues we discussed is to discuss the reality of life as a development shop.
Development shops are businesses and, like all businesses, they want to grow. They have their own obligations to their team members and funding sources. They will do anything they can to grow their business, and rightly so. We don’t begrudge them this.
What that means for you, the client, is that you may encounter the attention deficit development shop syndrome.
For example, if your development shop partner is pushing all of its resources into securing and working on a gigantic new project, you may find that your “little” $150,000 project suddenly isn’t getting the attention it needs or deserves.
In some ways, this is the easiest problem to solve and doesn’t require you to do anything new or inventive. You just need to communicate often and clearly with your project manager and even other roles within the development shop organization.
You need to be known, liked and respected not only as a client, but as a member of the team working on your project.
Development shops don’t usually ignore their customers on purpose. It’s just human nature to have limited availability of focus and attention. As a founder, you’ll need to make sure that you’re managing your relationship with your development shop partner in a way that provides you with the attention and focus you deserve.
Wrapping up
Look, we love development shops. We’ve worked with them, we root for them, and we promote them. But, like any loving relationship, we want to be clear on where and how things go wrong and hopefully how they can get better.
We hope this article presents a clear-eyed picture of what we, in our experiences, have identified as the key reasons for development shop meltdowns and what you can do to mitigate or, hopefully, avoid these issues.
Have you heard about Foundations by AppThink?
Interested in joining a group of entrepreneurs working toward their MVP? Join our flagship cohort-based course, Foundations.
Foundations is perfect for an entrepreneur with an idea but who is unsure of the steps to take to attack the problem and build a business. Do you have questions before you join? Send us a message, we’re happy to help.
