Just like it takes time, perseverance, and patience to build your character, developing a project’s scope can sometimes be similarly challenging.
There are two most common ways of cooperation with vendors:
- When you want a vendor to develop the product and support you during the ideation and design phase.
- When you have everything defined and just need the vendor to develop the solution.
This article talks about the first example: when you need your idea to be translated into a more tangible form.
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
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.
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.
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.