From Big Vision to Small Details
I like coming up with vision. I don’t have any issue
identifying how things may work 2-4 years in the future. Of course, prior to
doing that, I need to be comfortable with item I’m working with, and the market
that product sits in.
While this may not seem like a bad thing, it can sometimes hinder my ability to identify
details. I like to work from vision -> positioning -> requirements. I
don’t know why, but this is how I feel the most comfortable. Due to this, I
can have a tendency to work out requirements that pertain to building
the foundation of the vision I’ve already come up with.
I made a post a while back about going to market,
in which I discuss the steps I think contribute to delivering a product or
product module to market. One thing that I see that needs to happen right up
front is the creation of the vision statement for that item.
This statement includes a high-level overview for how the thing will work in
its initial iteration, and potential enhancements that can be made moving
forward. It assists with getting ideas across and segues nicely into the other
elements I mentioned previously.
Man, I love learning & realizing this stuff.
March 1st, 2006 at 5:31 pm
Brilliant. I love the Vision->Requirements hierarchy. Could you not extend it like this: Problem->Vision->Positioning->Requirements? Although, potentially the tree forks after the vision to document the positioning and requirements at the same time.
Anyway, well done!
March 1st, 2006 at 11:10 pm
Stewart, I appreciate the feedback. And I love FeaturePlan…I’ve only had a demo and know I’ll keep recommending it for use in the future.
I could see breaking things down as you mention — however, a problem should exist already if you are constructing a vision. A detail I missed mentioning, but definitely an important one to have.