Re: feedback/features/new loopers...

["David Kirkdorffer" <vze2ncsr@verizon.net>]

In my world of software, a lot of development is "keeping up with the
competition."  This often helps focus priorities - develop it, or lag
behind...and risk market death.

Certainly not all "user-desired" features fit with the "future vision,"
development capabilities or even understanding of a product's development
team.

For example with the Looperlative, I'm sensing that requests for a 96kHz
sample rate may not be reflected in this awesome new tool.  And there could
be very logical reasons for this: perhaps it's initial design does not
support this higher standard.  Perhaps implementing it would preclude other
(deemed more important) capabilities.

I'm not sure what process the Aurisis team used to drive the *continued*
development of the software in the EDP, but they did a great job in taking
in, understanding and leveraging "user input."   And I'm sure they didn't
heed every request either.  :-)

As I mentioned, V1.0 of a product sets the sage for the future, but often
mostly relies on the experiences, vision and passions of the development
team and selected influencers (various kinds of industry experts).  And 
it's
not wrong.  V2.0 is where the insight and forward vision of the software
architecture is tested, as new features and capabilities are added to the
existing software framework.

David Kirkdorffer


----- Original Message ----- 
From: "Kris Hartung" <khartung@cableone.net>
To: <Loopers-Delight@loopers-delight.com>
Sent: Saturday, December 31, 2005 6:52 PM
Subject: Re: feedback/features/new loopers...


> 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
> >
> >
>
>