Re: feedback/features/new loopers...

["Kris Hartung" <khartung@cableone.net>]

I like it, David.  One thing...do you also get exposure to the marketing
task of prioritizing features and needs, like L, M, H, or Want, Must, Good
To Have, Nice to Have, etc?  I've seen this a lot as well, which also helps
decide which features are incorporated, in addition to the development 
time,
cost, etc, which you outline below. Maybe that was in your part 3. :)

Kris

----- Original Message ----- 
From: "David Kirkdorffer" <vze2ncsr@verizon.net>
To: <Loopers-Delight@loopers-delight.com>
Sent: Saturday, December 31, 2005 3:24 PM
Subject: Re: feedback/features/new loopers...


> Loooooong posting - two parts
>
> Part I - Might be boring, if so move diectly to Part 2
>
>
> Part 1
>
> I've just caught up with a few days of LD - and there has been a great
> discussion regarding how products get developed.  To set a context for my
> comments, let me say my "day-job" has been marketing complicated software
> and technology for 15 years.
>
> A lot has been said already, and much of it I agree with. Let me add 
>these
> (perhaps already alluded to) thoughts:
>
> New products come from new "visions, " and new "visions" tend to focus on
> new ideas.  Without this, we would not see the innovation that has helped
> give us Loopers the range and choices of looping tools we have today.
>
> Successful technology products are more than a collection of features
> gathered together to solve some problem-set.  They need to be architected
to
> support "todays features" but also to support "planned future features."
> Just like with a house, you may not finish the basement, but you might 
>put
> in doors, stairs and electricity in advance to prepare for when you do.
>
> At some point however, the innitial vision that launched the product
becomes
> a somewhat "shared vision" as customers use the product in new and
> interesting ways.  Without paying customers, most products lose funding
and
> disappear.  Additionally, a sucessful technical product will need to
"grow"
> along paths matching the needs of customers -- or the product will be
> dropped when something better matching customer needs becomes available.
> That's why product managers seek and compile customer "Wish Lists" -
desired
> future capabilities.  Customer "Wish Lists" are a critically important 
>way
> to decide where to focus limited time on new features that will benefit
the
> most people.
>
> Striking the balance between "unique vision" and "market input" becomes
> critical.  The market tends to focus on the "now" -- and focusing on the
> "now" without thinking about how things will be the future indroduces
> inconstitencies and quirky interfaces.
>
> I agree with Kris Hartung's idea of soliciting ideas from the greater
> Loopers-Delight team.  It's a way to reduce the risk of the 
>Looperlative's
> failure.  What simple capability might have been overlooked?  How much
time
> should be dedicated to enabling which features?
>
> This is not in anyway to say Bob's vision is flawed or remis in any way.
> This is not to suggest Steve's dedicated and complicated work of Beta
> Testing the Looperlative is flawed or remis in any way.
>
>
> Part 2
>
> Version 1 of many products are more "vision" oriented and less "Wish 
>List"
> oriented.  This is natural.
>
> When it comes time for the Looperlative to solicit a Loopers-Delight 
>"Wish
> List" - (based on managing this for a company once) let me suggest a few
> things (and excuse my dry boring language):
>
> 1) Give the "Wish List" structure
>
> a) List potential / proposed features with descriptions of what they will
> enable and how they could be used; don't only use open-ended questions
>
> b) Make sure each Feature ALWAYS has a stated "Cost" in time - so
customers
> can see trade-offs
>     (this also forces the engineers to forcast what it'll take to develop
a
> feature)
>
> c) Break features into "Development Effort" groups
>      i) "Features that will take between XX and XXX units of time"
>      ii) "Features that will take between X and XX units of time"
>      iii) "Features that will take 0-X units of time"
>
> d) Possibly break features into "logical-sets" that go together
>      i) "This features-bundle will together give the capability to... and
> costs XX units of time"
>
> e) Use one open-ended question to let customers describe *capabilities*
they
> would like (not features).  Many times the customer is unaware that
desired
> capabilities are achievable with existing features.
> Also, this focuses ideas on the end results, and leave the engineering of
> "how to do it) to the product designers.
>
>
> 2) Give Customers a limited number of "Time Units" they can "spend" -- 
>per
> "Development Effort Group"
>
> You want customers to understand development time is limited, and choices
> have to be made.
>
> This tends to drive "votes" to the quicker to develop features.  Which is
> not always desirable.  That's why I suggest giving customers a limited
> number of "Time Units" to spend per "Development Effort Group"  (say, 30%
of
> total in a group).  That way you get votes for things across all
categories.
>
>
> NOTE: The results of any "Wish List" process MUST be tempered with the
> insight and vision from the product development team.  Just following
> desires in "Wish Lists" risks causing choppy, non-integrated product
> development.
>
>
> How far off-topic have I looped?
>
> David
>
>