Your Digital Product
will Never be Finished

MAKE A PLAN WITH THIS IN MIND
Digital products are increasingly a core aspect of business strategy, and more business executives are finding themselves responsible for complex technology initiatives. If you've never been involved in the creation of a new digital product, service, or platform, then I hope I can help by explaining the unique characteristics of digital product "projects".

Most business people think of a project as a discrete event with a start and a finish. Like building a new home — there is a design phase, followed by a construction phase, and then the project is complete. With a construction project, there is a discrete period of time, a specific outlay of capital, and when the construction is complete, most of the investment is behind you, as only maintenance is required going forward.
Despite technologists' tendency to use construction metaphors, designing and building digital products is completely different from designing and building physical structures. It's critical that before starting a digital product "project" the stakeholders fully understand the nature of the project they're entering.

To help frame this discussion, let's set up a scenario involving two hypothetical teams:

  • In New York, a $250 million services company identifies the opportunity to launch a new digital service that perfectly complements their existing business. They assign the new venture to a small team of senior execs that have no prior experience in creating digital services. The IT team of the company has historically only focused on internal IT support and company infrastructure.
  • In San Francisco, two friends decide to start a digital service targeting the same opportunity. One is a user experience designer, the other is an Internet software engineer. These co-founders either have cash in the bank from working at Facebook/Google or have raised some cash from eager angel investors.

As competitors, the teams above each have unique advantages/disadvantages. Since the San Francisco technical team described in our scenario already knows how to build software, I'm going to focus on providing guidance to the business execs in New York.
1.
Expect to invest heavily, or don't start at all
A digital product will never be finished. The nature of digital product development demands ongoing investment. Once a project is started, the only way to stop investing is to fully stop the project.

Therefore, the best way to save money on a digital product venture is to not start at all. Said another way, Castle has learned that the most valuable investment you can make is to perform thorough market research in order to assess the viability of the concept itself.

Much has been written on this topic of concept validation, particularly in regards to Lean Startup and Design Thinking. Regardless of the wisdom of performing extensive research up front, we still see entrepreneurs and businesses jump too quickly into product design and development, only later to find out that a major pivot is required in order to survive. Hindsight is 20/20 of course, but in-depth analysis and testing of an opportunity can surface these risks. Please read my prior post on evaluating your target market for more on this topic.

If the proper research and analysis has been performed and you are fully aware of the competitive landscape and its implications, then you may be ready to start your project. Just understand that there is no low-cost route to digital product success. Again, expect to invest heavily, or don't start at all.
2.
Your budget should be based on staffing and not scope
Given that your digital product will never be finished, the project will be a long-term venture and its budget should be considered as a monthly burn rate. Ask the question — how much money can you invest in your product per month and for how long?

For initial analysis, let's start by planning for two years. I picked two years because you will likely need this amount of time to start generating reasonable traction with your new digital product. The following schedule illustrates a likely 24-month timeline:
Months 1–6 The first version of your product reaches the market.
Months 7–12 Your customers truly engage with your product. You begin to understand how well your product meets the needs of the market. You iterate the product in response to customer needs.
Months 13–18 Your sales cycles take longer than expected or user acquisition is lower than anticipated. Accelerating the business requires more features. You continue to iterate the product.
Months 19–24 Your product nicely meets the needs of your market and you are acquiring customers at a nice pace. However, the product is never finished, as you feel competitive pressure to offer the best solution, and your customers are demanding more. You continue to iterate the product.
Given the two year timeline above, let's identify a budget that the New York exec team needs in order to be competitive with the startup in San Francisco.

To use some basic math, the team in San Francisco has one full-time designer and one full-time engineer. Let's assume they are at a senior level and would command annual salaries in the $100,000 – $150,000 range, so that together their combined annual salaries would be $200,000 to $300,000. On a monthly basis, their burn rate would be $16,700 – $25,000. Over a period of 24 months, their total salaries would be $400,000 – $600,000. If this team hired two more of their friends, which is a more reasonable team size, the team's compensation budget would be over $1 million for 24 months.

The table below summarizes the investment in salaries for a team of 2 or 4 technical resources for a period of 24 months (assuming $125k annual comp).
Team Size Monthly Burn Total 24 Month Cost
2 FTEs ~$21,000 ~$500,000
4 FTEs ~$42,000 ~$1,000,000
The dedicated product team of the startup in San Francisco has an implied 24 month budget of at least between $500,000 and $1,000,000. (This number excludes any equity compensation, and ignores the fact that top designers and developers can command greater than $125k and several points of equity.)

The correct method for budgeting the cost of a digital product is based on staffing over a long term duration as we did in the example above. It's rather simple math: the monthly cost of your team multiplied by the number of months you need to hit a funding or key business milestone (we assumed 24 months in order to be realistic).

The incorrect method for budgeting a digital product is based on features and scope. First, estimates are never accurate. Second, your product is never finished. So if you base your budget on a scope estimate, the result will either be over budget and incomplete or, if you are more lucky, under-budget but still incomplete.

At Castle, we combine both staffing-based budgets with scope estimates for the purpose of making sure that our staffing assumptions are appropriate for the scope and duration targets of the project. We use scope estimates only to help inform how many resources we need over a time period. But at the end of the day, our clients' budgets are based on staffing models.
3.
Your team should be dedicated and it will not be cheap
The startup in San Francisco has a full time, dedicated product team. The digital product market is competitive. Part-timers do not create market-leading platforms, products and services.

So the first step towards getting the work done is for the execs in New York to find a team that can be dedicated to their venture. They have a few options for solving this need: 1) hire their own employees; 2) hire some contractors; 3) hire a digital product company.

Let's analyze these options, assuming we are looking for 4 technical FTEs (the same team size as the startup in San Francisco).
Team Option Monthly Cost Pros Cons
Employees ~$42,000 Control Hiring
Independent Contractors ($125 per hour) ~$84,000 Variability Management
Digital Product Company ($100–$200 per hour) ~$67,200$134,400 Low Risk Cost
Given the options above, if I were to start a new digital product, I would hire employees due to the control and cost advantage. However, I have been in the software business since 1999 and know many talented designers and engineers that I'd love to work with again. Moreover, I know exactly what skills I'm looking for and exactly how to manage this team. Since the execs in New York are new to this business, hiring will be a blocker for them. It's unlikely that great designers and engineers will want to be full time members of their team out of the gates, even if they knew what to look for. There are just too many excellent job options out there today for the best technical talent.

The second option involves hiring freelance contractors. Assuming the execs in New York can find four proven individual contractors, the big risk of this move is that the management of the project will fall onto their shoulders. A comparable scenario would be if they decided to construct a building without a general contractor — choosing instead to manage the subcontractors directly without having ever built a building before. It could work, but this is the route that most often leads to failure.

The third option should be considered the safest for the execs in New York that do not have technical backgrounds. However, while the risk is low, the cost can be high — particularly with high quality firms with employees in the US, where the rates can be up to $200 per hour and beyond. Since a digital product is a long term venture, it's very challenging to assume that a business venture can sustain such a high hourly rate / monthly cost for up to 24 months. For example, running 4 FTEs for 24 months at $200 per hour is ~$3.2million for a team of four. This is about 3x the cost of employing an in-house team.

At Castle, we are able to offer dedicated teams at approximately 1.7x the cost of in-house resources, which makes it viable to run an outsourced team for long periods of time. Our ability to deliver high quality solutions at low risk for a more reasonable cost is one reason we are recommended from one client to the next.
4.
Low cost = high risk
Many of the nightmare stories of failed software projects are associated with the goal of trying to create a high quality result with a low quality budget.

Yes, there are high-quality, relatively lower cost digital product companies and teams around the world. I know some tenured software pros that have lined up some excellent relationships (not unlike what Castle has been able to do for itself), but this is the exception rather than the rule. These companies are challenging to find and may require trial and error before finding the right match.

Software manufacturing relies completely on the skills of the individual performing the work. There is a legend known as the 10x engineer — where an exceptional engineer can produce 10x more than a normal engineer — because coding is manufacturing without machine, leveraging an individual's unique experience and skill. The legend may be an exaggeration, but it's directionally correct. In fact, bad engineers can destroy value when their deliverables do not meet the needs of the business.

So if you are wanting to pay $20 or $30 per hour to a software development company, that implies that the person doing the work is getting paid $10 per hour by his/her company, which is less than US businesses pay for lawn maintenance. The world is flat and engineers are increasingly mobile or remote. Good engineers know they are worth more than mowing your lawn and do not work at these cheap firms. So with digital product design and development, cheap is generally bad and you are likely wasting your time and money.
5.
With software design and development, one FTE can not do everything
Creating a digital product requires multiple skills. It's common to cite designers and engineers, but those titles are just generalizations — kind of like doctors and lawyers. Staffing a dedicated team is challenging due to the requirements of different skills.

Let's assume the execs in New York want to launch a service that includes both a web-based experience as well as a mobile application. Here are the skills that are needed by members of their team:
Product strategy and management Someone to lead the product prioritization and roadmap that results in meeting the needs of the customers.
User experience design Someone to sketch, wireframe, prototype, test and measure the user experience solutions for the product features.
Graphic design Someone to make the user experience visually compelling and match the objectives of your brand.
HTML/CSS formatting Someone to format the graphic design files into CSS and HMTL files.
Web engineering (full stack) Someone to engineer both the front-end and the backend of your web software. Ideally this is one “full-stack” person.
Mobile engineering Someone to engineer the mobile software, which may be either web-based or native for a platform (iOS, Android, other).
QA Engineering Someone that establishes automated testing infrastructure and maintains the test suite. This person may also perform manual testing against test cases.
Development Operations Someone that establishes continuous integration and cloud infrastructure and manages the operations of software in development and production.
I know some engineers that can do all the tasks above, but not all of them with equal levels of skill. For example, a developer can probably design a web page, but it's not going to look anything close to Airbnb.

So when thinking about staffing and how many FTE's are needed, the matrix of skills necessary for a digital product comes into play and becomes a factor on sourcing the right team members. The Silicon Valley model is to try to find individuals that are "full stack" — designers that can code HTML/CSS; and engineers that can code frontend, backend web, mobile and do QA and devops. The more full-stack, high quality, and productive a resource is, the higher the compensation the individual can command.

This skills matrix (and level of skill inside this matrix) is an area of ruin for business people that seek to save money on salaries. If the execs in New York decide to hire a $75,000 developer, they may actually need 2 more hires to produce at the same level of one $150,000 developer.

The skills matrix is also challenging when considering small teams and small budgets. In my budget scenarios above, I referenced a team of 2 FTEs. However, it is difficult to create an advanced, fully featured digital platform, product or service with two people. The recent pressure to support web plus native mobile platforms has generally increased the team sizes needed to be competitive.

This is a gross generalization, but I'll take a stab regardless. The following table generalizes the design and engineering FTEs needed for different types of digital products in the initial early stages of their life. And since we have this table, we might as well fill in the budget (with a very wide cost range to cover your team sourcing options).
Product Type Team Size 24 Month Budget
New Venture (Limited Budget) 2–3 FTE $500k – $2.4mm
New Venture (Market-Leading Ambition) 3–7 FTE $750k – $5.6mm
Enterprise 6+ FTE $1.5mm – $4.8mm+
This is a really rough and generalized table. Feel free to reach out to me if you'd like to dive into these calculations deeper. The point I'm trying to make here is that the product teams that make market leading digital products are comprised of several team members that each hold special skills and contribute to the total awesome whole. It's tough to field a team of 2 individual people and get market leading results across the skills matrix. To cite a common example, Instagram had 13 engineers when it had 30 million users and was acquired by Facebook.

At Castle, we benefit from having over 85 team members and the ability to create staffing models where we utilize a combination of dedicated and fractional resources. For example, we may have 2 engineers plus 1/3 of three different people, which amounts to 3 FTEs. Fractional utilization is good for efficiency but it requires a higher level of team size and management to achieve.
6.
There is no such thing as "maintenance mode"
In the digital marketing agency world, there is an approach where the agency designs and builds some marketing technology (website or mobile app) and then hands over the deliverables to another lower cost firm or in-house team to "perform maintenance". Under this approach, the design and build phase is the glamorous/expensive part of the project, while the maintenance is second class.

When launching digital products, maintenance mode does not exist. In fact, it's the post-launch period where most value can be created with a product, because once it's in market the product can advance based on real customer data and usage. The reason we have concepts such as minimum viable product ("MVP") is so that the time and investment required to get the product to market can be minimized, and the time and investment allocated to enhancing the product based on live usage can be maximized. There is no maintenance phase. It's a fantasy, a myth, and a bad assumption.

The correct assumption is that your product must continue to advance at all times. The startup in San Francisco cited above has a dedicated team working on their product each day. It's not realistic to be competitive with a team like this if investment in a product is limited to just keeping the lights on.

However, it is realistic to assume that the investment in your product can have peaks and valleys across time. For example, there may be a burst of investment in the first 3-6 months of a project to get to market, followed by a more steady rate of investment. There may also be large items on your roadmap where investment is increased temporarily. The only rule is that you must continue to advance your product as best as your budget allows. As soon as you stop investing, you are at risk of failure.
7.
Keep your options open
I would advise the execs in New York to hire a digital product company to get their new venture into the market. But regardless of the route they take, I would also advise that they keep their options open.

The execs in New York can maintain the flexibility to adjust or change who's involved in their project by influencing certain key decisions of the project. Changing horses mid-project is not a positive event, but being "locked" into the wrong solution is even worse. The goal is to have a project foundation that is transferrable to another team in the event the first team fails.

A transferrable project is a function of the technologies involved and the quality of the project. In today's application design and development environment, there are certain technology selections that can make a project more adaptable across teams or team members. This is another area where we can advise further, but in general our advice to the execs in New York is to:

  • Utilize an open source web application framework such as Ruby on Rails, Python or Node.js. Avoid old school "enterprise" frameworks such as .Net or Java that require more cost and overhead and will not attract modern technical talent. We also don't recommend PHP. Also, where possible, use third-party open source libraries to extend functionality of the project instead of internally-developed proprietary solutions.
  • Push back and ask for reference projects if your team recommends using really cutting edge technologies. It's not uncommon for developers to want to try out the latest frameworks and technologies, even if there is no justification for these selections. Moreover, make sure your team can cite prior operational projects that they created with the recommended technologies.
  • Manage your code in Github or Bitbucket, embrace pull-requests with code reviews, and run your product in the cloud using Amazon Web Services or Heroku platform. Utilizing proprietary source management and traditional server infrastructure can block team agility and increase your costs.
  • Demand that your team build automated tests and utilize a test suite to run these tests. If you have to change teams or team members, the investment in tests will reduce the risks that the code written previously can not be easily operated or extended.
  • Encourage refactoring of the codebase as you progress. Refactoring is the task of re-writing code in order to support growth. If you defer code improvements, you build up "technical debt", and at some point you will have to pay this debt back. It's much better to pay back as you go so that the project remains in good condition.
  • Maintain documentation for your project that describes key decisions made during the project's lifetime. Documentation is needed for new team members to understand why specific technical or design choices were made.

At Castle, we enter into all projects with the assumption that we'll need to transition the initiative to an in-house team when the time is right. As a result of this expectation, we take steps throughout the project to make sure this transition is possible.
In Summary
It's not easy, but with the right budget and right team, anything is possible
The execs in New York can indeed compete with the startup in San Francisco if they enter the project with eyes wide open and embrace the absolute need to budget properly, invest in a quality dedicated team, and have a long-term project point of view and runway.

Feel free to contact me at [email protected] if you would like to discuss this topic further.