Hypothesis and Measurements
The scientific method is founded upon taking carefully planned measurements to support or disprove a hypotheses. Measurements are a critical component of this process. Observations are matched to theory, and either strengthen or refute the supposition. An interesting footnote in this process is that there is usually a wealth of information in the measurements that is ignored for a single study.
In order to minimize the effect of bias on findings, scientists are best served by detaching themselves from each theory they seek to study. I see that this pattern extends far beyond labs and universities, even into the realm of early startups.
Muppet with a Point
This dates me, but I am a big fan of the Empire Strikes Back film. At one point in the movie the protagonist Luke is undergoing Jedi training with master Yoda (the muppet). Yoda makes a comment that is very applicable to early startup founders:
"You must unlearn what you have learned"
The point for founders is not to forget all they've learned, but to put that learning and assumptions under critical review and not let bias hamstring design choices.
If you just started working on a startup, you certainly have a hypothesis. But you may have no indication of how much traction the idea will have (we all want those future goggles). By implementing simple prototypes and bug ridden alpha versions you begin to gather feedback. If the idea is untenable it gets rapidy dropped, but if there is early success the idea evolves. We're in a highly dynamic design phase at Victus Media (there's two of us) and have had some interesting early findings.
As our discovery portal progresses (yup info overload, we're working on it), metrics become an excellent pulse on its performance. Right now the metrics are me asking friends, "do these entities make sense based on your status updates?" I've been fortunate to get quick feedback, even though our latest push has a few bugs (most new feature pushes do). We'll have them hammered out shortly and move on with plans to stream line the search page.
The hardest part of design, is coming up with a compelling reason for users to visit, return, and love your work enough to tell their friends to check it out.
It is when making future design decisions that bias can play a terrible role in blinding one from opportunity. Everything we've done so far is mutable. Tying ourselves to a framework, database, interface, or service is silly. Both Tyler and myself are highly critical of our own work, our reaction when interacting with our site is usually "so what". We both expect that when we come up with the right combination it'll be pretty obvious, and easy for users to understand. At the point that the project transitions from unknown to execution, we'll celebrate. But that's when the work of business building kicks into high gear.
This post is a reminder to myself to not get too attached to specific tactics while working towards a bigger goal (create massive user value using available data).
Related articles by Zemanta
- Data driven science revisited (mndoci.com)
- Keeping computers from ending science's reproducibility (arstechnica.com)