The product I'm going to make could be very large. There are loads of features it could support, but one of the first jobs I need to do is decide what it must do for a first release, that delivers value to customers. I've started getting in touch with small business people that I know to understand what they would value in such a product, but there are just so many diverse suggestions, even when I've given them initial scope for what I think the first release could do. I find myself thinking "that's easy, that'll only add a day or two" to certain features, but I'm fairly confident when it comes time to design these things, the duration and complexity will explode.
One thing that is common in pharmaceuticals (@mrsrickerby works in that industry, so I have a little understanding of how things work there) is that a "Core Data Sheet" - aka a core product specification - is written before and during development and testing of the product . This document specifies needs and wants which at the end of each phase of development are used as the yardstick to make go/no-go decisions. For example, if you want to show a 5% improvement in some disease state but your phase 2 study doesn't achieve this, you stop development. It is a living document which, as data is collected, the actual product profile is documented which ultimately becomes the package insert (the bit of paper in the box).
This made me think about how I can manage my scope. The main marketing materials for me will be (1) a web site and (2) the Mac App Store description. I figure that writing the app store description will be the most effortless way to describe the product, the problem it solves, and how it solves that problem for the customers. If I can't write down the very simple things like what problem this solves, and how it does it, then I should stop right now.
I think this also aligns with something I read recently (although I swear I've read this before months and months ago...) from the world's toughest programmer, Mike Lee. App Genius Mike Lee Talks Product Engineering mentions that you should produce some marketing materials (he suggests a video) to explain why people should buy your product. I don't plan on making a video, but the app store description fulfils the same purpose, and I'd argue that it's more valuable, as it saves on a job later as it will be refined over time.
This is the approach I'll be taking to my scoping.