Link: http://gettingreal.37signals.com/ch02_Build_Less.php

Underdo your competition

Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they're spending x, you need to spend xx. If they have 20, you need 30.

This sort of one-upping Cold War mentality is a dead-end. It's an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can't think ahead, they can only think behind. They don't lead, they follow.

If you want to build a company that follows, you might as well put down this book now.

So what to do then? The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of oneupping, try one-downing. Instead of outdoing, try underdoing.

We'll cover the concept of less throughout this book, but for starters, less means:

Less features
Less options/preferences
Less people and corporate structure
Less meetings and abstractions
Less promises

Something else that might be worthy of adding to 37Signals essay...

One of the suggestions I would add to the essay is:

“Keep less data”

Keeping a lot of data is a pain. Indexing, partitioning, tuning, backup and recovery – everything is more painful when you have terabytes instead of gigabytes. And when it comes to cleaning data out, it always causes endless debates on how long to keep the data (3 month? 7 years?) and different life-cycle options (move to “old data” system? archiving? how to purge? What is the process?).
What’s more, a lot of the time customers would really prefer we won’t keep the data. Maybe its privacy concerns (when we keep a lot of search history) or difficulty in generating meaningful reports or just plain confusion caused by all those old projects floating around.
Google taught us that all the data should be stored forever. But perhaps your business can win by keeping less data.

Pages: 1 · 2

Link: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::NO::P11_QUESTION_ID:54226589195717#PAGETOP

Interesting running thread on Asktom.oracle.com regarding datamasking. I provided my two cents into the picture.

Does Oracle provide a package or function for data masking ? For example, in a
development environment, for data protection purposes, the information of the table
customer needs to be masked.

create table customer (last_name varchar2(25), first_name varchar2(25), address
varchar2(25));
insert into customer values('Doe', 'John', '10 someroad st');

In the production environment, if we do a select on customer, the result would be without
any surprise:

select *
from customer;

LAST_NAME FIRST_NAME ADDRESS
-------------- -------------- --------------------
Doe John 10 someroad st

In the development environment, the same information needs to be masked for something
like:

LAST_NAME FIRST_NAME ADDRESS
-------------- -------------- --------------------
Ahd Uiea 55 xxxx ue

It doesn't really need to make sense, it doesn't need to be readable. Just needs to be
masked. Does Oracle supply anything for that purpose at all ? I tried to find but didn't
have much success. I found a third party software that will do the job. If you want to, I
can post its name here.

Thanks Tom and happy 2006.

Gleisson Henrique

and we said...

No, we can "hide" the information (Oracle 9i provides for row hiding and Oracle 10g
provided for row and/or column hiding)

But data obfuscation - no, it cannot do that. You actually need to physically obscure
the data itself prior to storage (and it had better be a one way obfuscation). Think
about things like indexes and such.

Don't forget, as soon as you start obscuring data, you start to loose the natural
distribution of data. Do not be surprised when your obfuscated system behaves entirely
differently from your "clear text" system - clustering factors, data lengths,
distributions of values - all will be radically different.

I'll post to see if anyone has a suggestion on a tool to use sparingly on names/addresses
and the like.

Link: http://venturehacks.com/articles/minimum-viable-product

I recently say down with Venture Hacks for an interview. Part one is up on their site today, in text, audio and slide format. Here are some topics and excerpts of what we covered, edited lightly for how I wish I'd said it at the time. To hear full audio and a complete transcript, click through to Venture Hacks.

Is "release early, release often" enough?
The issue there is, if you just follow the release early, release often mantra, you find yourself running around in circles, because you ship code, you get some feedback from people, you do a focus group.

Customers say,”Give me feature X,” “Give me feature Y,” and sometimes you do what they want, maybe sometimes you’re going to do what you want, and then they get mad at you. Pretty soon you’re chasing your own tail a little bit because you’re not operating against a clear, long-term vision of what you’re trying to accomplish.

The idea of minimum viable product is useful because you can basically say: our vision is to build a product that solves this core problem for customers and we think that for the people who are early adopters for this kind of solution, they will be the most forgiving. And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.

So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.

Solving the chicken-and-egg platform problem
Developers don’t want to develop unless there are customers who are there to buy their products, and customers don’t want to come on the platform unless developers are there selling them something useful.

What we did is we took early adopter developers and we told them a story about how IMVU was going to take over the world and be this really powerful product for mainstream customers ... and we gave them an economic incentive that said, the earlier you get on board with the platform, the bigger your take is going to be for derivative products that get created down the road.

We shipped a product that had almost no customers — certainly no mainstream customers — but, because we had told that story effectively and we really understood those early adopter developers, we got a ton of them on the platform developing. They felt like they were in the middle of a gold rush, despite the fact that there was really no evidence to support that belief yet.

Starting with just a landing page

What we should have done, and what we did for a lot of features thereafter, is started with a landing page that promised people that product. Then we should have taken out the AdWords we were planning to take out, drive traffic to that landing page, and offer people to buy the experience that we are talking about.

What we would have found out if we were doing that experiment is 0% of people would have clicked through, which means it doesn’t matter what is on the second page.

The first page is so bad, not because it is badly designed, but because the features are wrong that you don’t need to go through the effort of building out the product. So we wished we had done that, and we did make that mistake really

Overcoming the fear of the false negative

As long as you’re not afraid of the false negative, that is, if you don’t get discouraged because you’ve built your first paper prototype of it and shown it to people and nobody wanted it. That can’t mean that like you give up because,”Oh, forget it, we’ll never make it.” You’ve got to say, "OK, well then let’s iterate some more.”

If you keep iterating at it, you keep making it a little bit more sophisticated, at a certain point after you’ve been through 10 iterations, that you still got no uptake whatsoever, and the feedback you’re getting from customers is still a yawn, you might say to yourself,”You know what? We’re not moving in the right direction. In fact, we’re past the point of minimum viable product. This just isn’t a viable product.”

Read the rest of the interview at Venture Hacks.

Got to thinking that it would be interesting to create a Google Earth Tour of where I have been.. from birth to today. So I dragged out this old piece of paper with a list of places and dates. Having grown up in the military, I have been to a number of places. I figured I would start mostly with where I lived, then move to filling in the gaps with places visited while there. For the most part the tour file is in order, and then sporadically filled with some highlights.

If you want to run through the tour yourself, grab a copy of Google Earth and then grab this file here to walk through the tour. Its under 10 minutes right now. Who knows down the road. Guess I will see where it takes us...

Where Have I Been

Found these on YouTube regarding Agile Development. Found them very informative and possibly a introductory tool for business when introducing Agile methodology for the first time.

Agile Methodology is a tool like any other tool... right time and right place. Agreeably more often than not it could be the right method to engage.

You can download the videos here, both of which are under 10 minutes each. The downloads are not streaming. If you want streaming versions, I am certain you can find them you YouTube.

Agile vs Waterfall : A Tale of Two Teams
SCRUM in Under 10 minutes