How to start scoping?

Evaluate where you are starting. Are you starting from zero or have you already accomplished a certain amount of work in trying to define what your product is? What have you already created,  produced, or defined - anything you can share to help create some kind of a scoping reference for the team you’ll be working with. Can someone else start to understand your idea and your vision?

Some questions to consider…

1. Who is this product for? 
2. What problems does it solve? 
3. What are the business objectives? 
4. Who are the people that are gonna be using it?
5. How are they gonna be using it? 

Understanding Project Ranges

A product of any kind, from a web, mobile, or custom software perspective, could have a wide range of costs. The more you invest in defining what your scope needs to be and who it's for, the more you can leverage a budget that will work for your project.  

The House Analogy

You wouldn't ask somebody how much a house costs without giving them some idea - where is it? How big is the lot? How many square feet is it? Otherwise, you could be talking anywhere from a hundred thousand dollars to tens of millions of dollars. The same goes with software. You’ll want to be as transparent as possible in the beginning, in order to be able to produce the results that you want and that are within your budget. 

Is there room to grow after you set your scope?

• This is where we lean on the strategy team with our clients to see where they are at. What is their particular industry vertical like? What is their niche like? What makes the most sense when it comes to developing software?
• Do we take a very bare-bones, MVP approach that might be a bit more cost-effective and agile to develop? Or is this a critical, "it has to be right on the first go", release? 
• A lot of these things get easier to figure out the closer to the deadline you get because requirements change, constraints change. It's easy to sit down and whiteboard- plan all of it out and then once you get into the reality of the situation, you might realize you need to pivot some, and all of this is happening while the market's ever-shifting.

Knowing when to sit in your project’s definition

Understand that you could work on the definition forever. Look at what the objective is. Are we trying to get something to market as soon as possible at the highest quality possible with a minimum feature set? There's a goal that needs to be met there. A lot of times, things can get a little sideways when the ideation phase of the project never really stops.

• You want to get, where you know what your core personas are, you know what they need, you know what problems you're trying to solve and you have an idea of what your go-to-market plan is. Even if go-to-market is an internal review of some sort, you satisfied the definition to the point where you can meet that milestone.
•  If there are timeline or budget constraints that are driving the project, ensure that the entire team has to be aware of those constraints and know when those trade-offs need to be made. 

Don’t be afraid of an MVP!!

Rapid prototype style development is one of the best happy mediums if you're caught somewhere between, "I have all these great ideas and I've thought it all the way through, but I've not really started yet." Take pieces that are much more budget-friendly and just build out units of that. While doing that, do it in a paint-by-number way where we know where all the numbers are, but we're just going to paint in the certain things that we're able to, and bootstrap an app that way. Break it down to components where you can answer “If nothing else besides this MVP is built, will this still work?” Prioritize the components that do work, because those are going to be much more budget-friendly to get out there and see working.

What should we consider technically?

What platforms do you want to be on? (by platforms, we mean the web, android applications, iOS applications, etc..). 

• The more places you are, the more expensive it is. If you want to make an offering in all of those different markets, there's a barrier to entry for each of those regulated markets. App stores are a lot more guarded and require a lot more care than it would take to just build a website. 

How many people do you intend to use this application? Where are they?

• You can make a website that's hosted off of a laptop in a closet in your office, and that can be your server. And if you're only using it within the office, you might be able to get away with it. But, If you want to provide something on demand across the globe, we're talking about using advanced cloud architectures that are able to run things. So this is one of those cost sliders where we always ask:

1. Who's the target audience here? 
2. Where are they geographically?
3.  How many people are you trying to target?  
4. How long are they gonna engage with it?

What work does the software do?

On a spectrum of complexity, on the light side of this is Content Delivery software (like Twitter) where users are consuming the information. Sometimes they're providing information and consuming information. As we move into more complex software, the delivery of those includes more calculating and automating features, which can do a lot.

• (For Example) If you go to any big box store, all of their inventory systems are terminals. They don't need to be very super user-friendly because the stores train their people to use the systems. But if you're trying to provide a powerful application to novice users who may not be trained, then it takes a lot more work to prepare for all of the different circumstances and give a human the ability to influence the software in a way to attain an outcome that they would anticipate.

Don't get caught up on specific vendors or the cloud architecture setup you go with.

• A lot of that is secondary to exactly what it is you're building and the complexity:

1. Where you want this available?
2. How often do you want it available?
3. What kind of uptime do you want?
4. What does the software actually do at the end of the day? 

Plan ahead!!

If you think that there's a shadow of a possibility that you're going to want a dedicated Android or iOS app, establishing that up front will be key.  

• The cost associated with switching platforms is something that a lot of people may not understand. If you have a budget constraint, it is often good to use a hybrid platform, which is essentially a coding platform where we can build your application in such a way that it can be deployed to the web, iOS, Android, or any mobile app really, from the get-go. It may cost a bit more than the option of solely creating the website, however, it will save money in the long run if you decide to create an offering on a mobile platform.   

Understand that it's pretty rare to build a software product and then just finish building. 

• You will have to budget for product updates and maintenance going forward. Sometimes, that can be a surprise for people; they think they're going to take possession of their software on some particular date and it's just gonna work in perpetuity for all of their customers. In most cases, that's pretty rare.

Questions to ask tech agencies

1. what is my monthly cost going to look like?
2. Does my product scale?
3. Does it scale with the number of users I serve? 
4. Does it scale with time? 

Be transparent about your budget!!

It might seem counterintuitive or like a negotiating tactic where feel like you need to hold information back. But, in the same way that you wouldn't ask somebody to give you a quote on constructing a house without a budget, you wouldn't want to do that with the software either. And it's for your benefit.

If you know that your budget is $50,000 and you don't articulate that to the people that you're potentially going to work with, their estimation process is going to be purely based on every idea you've been able to put out there so far. If you tell somebody upfront that you have either a hard budget, restriction, or a range, you're much more likely to get everyone thinking about how to hit and stay within that number. It's really more about creating some boundaries around what this product might be, what the abilities are, and who it's serving within the price point that's out there.