Support
Looper's Delight
|
Support |
|
|
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