Preparing the Scope for Your Project — What to Know Before You Start

Key Takeaways

Be prepared that defining the scope takes time — the scope will be changing, evolving. This is a never-ending back and forth game. During the development, new things and ideas will come up that will further influence and change the scope. It’s fine.

Talk to people about problems to gather ideas and feedback. The vendor will help you make sense of it — without enough product experience, you might miss key insights from user interviews. Bring user problems and feedback you’ve gathered to the discussion with the vendor.

Don’t try to use every template — even though there are numerous templates such as Lean Canvas, whether you should use them all depends on many factors. For example, if the product will be the core of your business or maybe an extension to a process. A vendor’s product managers will help you go through these templates in the most efficient and results-oriented way.

Be proactive — scoping the product is an ongoing process. You need to actively participate in all discussions, giving feedback and sharing your thoughts as much as possible. This way you will transfer the knowledge to the people who are the experts so that they can help you scope the best first steps of your product.

The Anatomy of Project Scope

Creating a project’s scope depends on many factors like business goals, product vision, users needs, and product feature requirements. Scoping requires close partnership and collaboration between the vendor and the client. It also takes time to turn your vision into specifications ready for the next phases.

Here’s how the scope progresses in granularity:

• High-level assumptions
• Mid-level requirements
• Low-level specifications

High-level assumptions

The high level contains more general assumptions like what you want to achieve, initial technology assumptions (e.g., tech stack, platforms, and other systems and integrations). It’s the description of what you want your product to be: a simple overview, without anything tangible like feature descriptions, mock-ups, or designs.

Mid-level requirements

Here things get a little spicier because you’re getting into the details of your idea. For example, figure out use cases for different personas — what users should be able to do in the product. It’s also when the design enters the scope in the form of wireframes or mock-ups. In other words, the mid-level scope shows you how the app can look and what it can do. This stage ends in project requirements, general backlog (EPICs, first user stories), and general UI requirements.

Low-level specifications

It’s where your vision is translated into implementable backlog items, well-defined user stories. In other words, features developers will be working on. In this level of granularity, you’ll also consider what’s technically available and viable. Think of low level as product specifications.

The Complex High-Level to Low-Level Scope Progression

The goal of getting from high-level assumptions to low-level specifications is to close the gap between what you and users need, what the vendor understands, and what is feasible to do.

To create requirements and specifications that meet user needs, the vendor has to deeply understand the users and their problems. Without an almost intimate experience of the user's problems and needs, creating a project scope is often a guessing game.

To build a good scope, take into account:

• The user environment — what will trigger the users to use the product?
• Available budget — how much are you willing to invest to get the first business value? (read more about MVP, a prototype, and PoC)
• Business model — how do you want to market your product and monetize it now and in the future?

This level of knowledge isn’t something that can be worked out in a week. Again, defining a project’s scope takes time.

Immersing the Vendor

The vendor never knows as much as you do about your product or business — it’s the so-called “curse of knowledge.”

“The term ‘curse of knowledge’ is somewhat tricky as the problem here is not really what you know but what you don't: the gaps between your knowledge and that of your vendor. It's only when these gaps are identified and filled that we all start moving toward a shared understanding of what needs to be done,” says Jarek Szymański, Product Manager at nomtek.

You may assume that the vendor knows where you’re coming from and that the vendor’s existing experience can be reused in your project. While you often don’t need to reinvent the wheel, project complexity and your differentiations can make your product special every time.

“One way to get aligned at the outset of a project is to empathize with your vendor, try to see things from their point of view. What do I know that they don't? Can I anticipate their initial questions and think of the best answers even before they are asked? How can I prevent confusion by providing key information at an early stage?” Jarek says.

To help the vendor better understand your product and business, prepare a brief. The brief should explore the wh- questions (i.e., who, what, when, where, why, how).

For example, the brief can answer the following:

• What do you want to build?
• Who is the end user?
• What is the problem your product will solve?
• How will you solve the problem?
• Is there anyone else out there who offers something similar (you direct and indirect competition)?
• How will you measure the success of your product? What is the desired outcome?
• When would you like to launch the product?

The Rise and the Fall of the Lean Canvas (And Pretty Much All Other templates)

Disclaimer: Lean Canvas and other product development templates are great frameworks for fleshing out your idea and creating the necessary assumptions. We’re not discounting them but rather pointing out that many nuances have to be considered when working with any framework.

All tools that help structure the business model are only that: tools. They shape your thinking, but if you don’t know how to use them, they won’t necessarily yield the expected results.

It’s a long way for an idea to turn into a product specification. Countless websites and software agencies encourage entrepreneurs to fill out the templates. While templates help you understand your idea better and structure it at the beginning, you might forget about their results in later stages. Moreover, if you don’t have much product experience, you might struggle to grasp actionable insight from these templates. Also, the content of the templates you've filled out will change many times along the way.

The solution cul-de-sac

When you come to a vendor with filled templates, you might fall into the trap of coming from the solution space. In other words, you have an idea of what the product should solve without exploring the actual problems of the target audience.

“When you start with a solution, you tell people that this solution is what they need. But you don’t really solve their problems. Starting with a problem lets you stay open to many ideas and approaches. A solution usually evolves, so when you come up with one solution and get fixated on it, you’ll have a hard time creating something else, presumably better. The solution changes, but the problem remains,” says Marta Kwapińska, Product Manager at nomtek.

We suggest coming from the problem space — what problem you want to solve. Talk to your potential customers, figure out their pain points, analyze gaps in processes, and let them understand alternatives to the status quo they have grown accustomed to.

Consider the differences in a solution-oriented mindset vs. problem-oriented mindset.

Solution-oriented mindset:

• You’re focused on one solution. You get attached to your idea, thinking your solution is always the best. This mindset blindfolds you.
• You don’t see your users and their needs.
• You’re not open to innovation.
• You “force” the solution to people, telling them it's what they need. But the solution rarely solves their problems.

Problem-oriented mindset:

• You’re open to many solutions.
• You’re directly working on a user’s problem, so you don’t have to prove anything, except that you’re trying to solve it well.
• You’re working on the problem, so the solution can change, evolve, and adapt.

Cooperation and Involvement Are Prerequisites to Building the Scope

Take on an active role in the project from the start. Participate during meetings, give feedback, and be involved at all times in the decision-making process. In other words, without your input and visceral knowledge of your business, the vendor might lack the core insights to build the product.

The vendor needs complete immersion to build a scope that involves solutions to user problems. But keep in mind that once complete, the scope is not finished — as your product evolves and you learn more about your target audience, more user stories are likely to emerge.