... I ve always felt that any business model that hopes customers will behave stupidly is bound to fail in the long term. This company will be successful inMessage 1 of 62 , May 19, 2006View SourceAt 11:33 AM 5/19/2006, Lynn Miller wrote:
>I know a company (NOT the one I work for) that puts out absolutelyI've always felt that any business model that hopes customers will behave
>crappy software that is unusable. The company is successful because
>they price it very cheaply ($99) and make sure that they have checklists
>of all the main features that the useable ($2000) software has. Novice
>users buy this software, realize too late that it doesn't actually work,
>then buy the higher priced software. This is a business decision of this
>company and it makes the company successful.
stupidly is bound to fail in the long term. This company will be successful
in the short term, but since they always need to acquire new customers,
instead of selling newer products to existing customers, their sales
expenses will be substantially higher and will make them less competitive.
The Chia Pet <http://en.wikipedia.org/wiki/Chia_pet> was very popular, once...
Jared M. Spool, Founding Principal, User Interface Engineering
510 Turnpike Street, Suite 102, North Andover, MA 01845
978 327-5561 jspool@... http://www.uie.com
... Which, honestly, I don t think is unreasonable. From the perspective of the waterfall person, all problems can be solved with a little more planning, andMessage 62 of 62 , Aug 31, 2006View SourceAlexander Johannesen wrote:
> If you can hide your work from them,Which, honestly, I don't think is unreasonable. From the perspective of
> then great, but there is this notion of teamwork going on here that
> requires a certain ... mediation to old progroms.
the waterfall person, all problems can be solved with a little more
planning, and failing to plan it all up front looks dangerous and the
fast route to failure. Until you have seen it work, it's easy to believe
that agile processes are impossible. I sure did.
When dealing with people like that I'll generally try one of two
approaches. The first is "Well, let's try an experiment." We find some
level of risk that they are comfortable with and try out agile methods
in that context. If the experiment is a success, we try a bigger experiment.
The other is, "You do what you think it takes." If they want a big spec,
then sure, they can write one up as we have our discussions around the
product. If they think a continuously updated spec is important, then
great, they should keep updating it. If they want a big MS Project
thingy, fine, we'll make sure all the necessary data is on our wall of
I don't know if those are helpful to you, but they've worked for me.