The Man Who Saved Windows Explains How To Decide What A Product Will Do

APA lot goes in to determining how to develop a product, from deciding which features to include to figuring out the right way to market it.

But the most important first step is to decide what the "scope" of the project is, former President of Windows Division at Microsoft Steven Sinofsky writes on his blog Learning by Shipping.

Here's how to do it:

You first need to determine if it's an entirely new product, an evolution of an existing product, a complete overhaul of an existing product, or one that works alongside another product. That's because "scoping a product is an engineering choice, not simply a way to position the product as it is introduced."

• If it's an entirely new product, you can express to your team the smallest set of features and investments. But you need to take into account if the product is entirely new to your company or new to the entire industry.
• If you're improving an existing product, you need to take into account how compatible it will be with the current product, in terms of user experience, data, platform, and features.
• When trying to disrupt a pre-existing product, be clear about exactly which part of the project you're changing.
• If it's a side-by-side product, you must determine how the new product will work in conjunction with the pre-existing product.

But there are some common pitfalls in scoping that a team needs to take into account as the product goes from the planning stage to execution, Sinofsky writes:

• Deciding to revisit the scope of the project mid-way through. For example, changing from disrupting the product to evolving the product will likely put your team off schedule.
• Attempting to do "too much" than you can feasibly get done with the amount of time and resources at hand.
• While a minimum viable product is good for developing new ideas, you need to make sure you don't "scope the product to do too little."
• Attempting to solve the wrong problem.

Another thing to take into account is the mechanical and strategic constraints to the product, Sinofsky writes. "One way to think of these constraints is as the key variables for project scoping—you rightsize a project by choosing values for these variables up front:"

• How many people will be working on the project?
• How long will the project take to complete?
• What kind of tools and code will be necessary?
• What huge bet is the project taking?
• Who will be using the product?
• What's the long term plan and goal for the project?