John and I went to the Web 2.0 Expo in New York City last week to learn about new trends in Web 2.0 and to try meet interesting people in the industry. We had fun, and I even won a Flip Ultra HD from the folks at a party hosted by Rackspace and Neustar. This post includes my notes from various sessions from the weekend.
Web 2.0 Expo kicked off with Ignite NYC on Monday (11/16) night. We're a big fan of Ignite talks (having created the websites for Ignites in Baltimore, DC, Annapolis and RailsConf) so it was exciting to check out Ignite in the Big Apple. The Ignite NYC website lists the speakers but doesn't mention what they spoke about (we'd be happy to host your website). Unfortunately I didn't take notes at this event and I'm not going to go through all the youtube videos right now, so I don't have much to share.
Web 2.0 Sessions
NoSQL: The Shift to a Non-relational World
This talk, given by Dwight Merriman, was about non-relational databases, which is a different paradigm from traditional databases like MySQL, Oracle, MS Access, MS SQL Server, etc. Non-relational databases are interesting to me as I think they might be applicable to some of our client projects. My notes:
- No joins
- Uses map reduce instead
- When considering scaling out - think about "CAP" - you can pick any two of the following but you can never achieve 100% of all three:
- C onsistency: ensuring that data on multiple database servers are consistent
- A vailable: you want the database to be available when you need it
- P artition-tolerant: partitioning the database to run across multiple servers
- CAP constraints are most relevant when writing to the database. If you're only reading from the database, it's easy to have all three.
The Lean Startup: a Disciplined Approach to Imagining, Designing, and Building New Products
This talk was given by Eric Ries (@ericries), who blogs at Lessons Learned. He is someone with whom many tech entrepreneurs are smitten, and I must say I myself was impressed. My notes:
- Devs can check code in, gets deployed everywhere within 20 minutes
- Cluster will detect bad changes to the code, revert them, email everyone
- The example Eric gave was that if someone messes up the UI of the checkout
screen, e.g. changes the "pay now" button such that users can't see it
and this causes the company not to receive payments, the system will automatically
revert itself after 20 minutes or so.
- Commodity Technology Stack
- Customer Development
- Agile Product Development
Agile Product Development
- Principles from Lean Manufacturing, Agile, and TPS
- Unit of Progress: A line of Working Code (as opposed to advancing the plan in waterfall). Problem: known, Solution: unknown.
Product Development at Lean Startup
- Unit or Progress: Validated Learning About Customers ($$$)
- Problem, Solution: unknown.
- Hypotheses, Experiments, Insights feed into XP, which feeds Data, Feedback, Insights back into Problem Definition / Customer Development cycle
- Problem team: (formerly sales, marketing, product development) - cross functional team
- Solution team: (formerly engineering, ops) - but should also include marketing - cross functional team
Pivot: one turn through this feedback loop
- Ideas - build - code - measure - data - learn - back to ideas
- Minimize total time through the loop
AAA's of metrics:
Accessible - must make sense to anyone, and must be accessible by anybody in the company (everyone should be able to pull the report)
- Most useful thing is to kill pet projects and help people see that pet projects are bad ideas.
Auditable - "metrics are people too" - reports come from tangibles
when someone sees a report, they must be believable and must stand up
to any questions. People must be able to audit them because initial
human reaction is to doubt and deny, etc.
Measure the Macro
- Always look at cohort-based metrics over time
- Split-test the small, measure the large
- A technique for continuous improvement of company process.
- Theory: behind every technical problem is a human problem
- Example: imagine a server crashes. Why? Code got deployed
that used some obscure API that caused it to crash. Why? Person
that wrote the code was a noob engineer and didn't know better and wasn't
trained. Why? Manager
doesn't believe in training. Started with a server problem ended
up with a management problem.
- Ask "why" five times when something unexpected happens.
- Make proportional investments in prevention at all
five levels of the hierarchy.
- Behind every supposed technical problem is usually a human problem. Fix
the cause, not just the symptom.
- Helps us identify that we're too busy to find out why we're too busy
- Acts as a natural speed regulator. If we're spending too much time
fire-fighting - we'll have to slow down to address problem, etc. Regulates
Minimum Viable Product
What's the absolute least amount of product we can build to engage the
Instead of asking customers what they want (which they don't usually
know), we're going to take our theory, put it out there, and TEST.
Visionary customers can fill in the gaps on missing features - if the
product solves a real problem.
- False negative: customers would have liked the full product, but the
MVP sucks, so we abandoned the vision
- Too busy to learn: it would be faster to just build it right, all this
measuring distracts from delighting customers
- False negative: customers would have liked the full product, but the
Must have an agreement with the team to iterate - just because clients
don't like the first version doesn't mean they're not going to continue
Eric mentioned a book he's publishing: Startup Lessons Leaned (book) - still in "beta." He also recommended The Four Steps to Epiphany.
Sketchboards & Prototyping - Method for Rapid Design
This talk, given by Todd Zaki Warfel (@zakiwarfel), described a process his company uses for prototyping ideas for applications. It was my favorite talk from the conference. Todd's website is at http://zakiwarfel.com/. My notes:
Prototyping is a process
People often say "I think I get it but I'm gonna have to see it" -
need to see prototypes
Todd's company doesn't do wireframes. Their wireframes are their
might be sketched out on paper. Click-through wireframes are their
prototypes (XHTML/CSS). They do production-level prototypes, not recommended
for anybody else.
Two main reasons for sketching / prototyping in the process
Sketches are a great communication tool - don't write notes - sketch
Pics have less room for interpretation than text
Lo-fi is cheaper, generally speaking, than doing AI, etc.
No written requirements - just visual requirements
"Agile Conference" - 1500 - 1600 people show up. Todd's group
made some app in two days, for charity, and raised a few thousand bucks with
Design Studio Method
Industrial design / architecture method
A methodology where you build something, sketch something - create an
idea - and then show it to people, let them critique it and tell you what's
good and bad about it. Then iterate. Take an idea, put it out
in front of people, rip it to shreds, etc. But you get to do that
to their designs as well.
They'll do the Design Studio Method sessions with their clients and get
paid for it.
Write down a few keywords to describe the product today
Write down a few keywords to describe the product 6-9 months from now
- print this out, put it in big words in the room
- --> allows them to see their goals --> see what it is now, and
what they're targetting
- Personas - people that are going to
- Inspirational printouts - stuff that looks aesthetically good or stuff
that has good interaction - stuff to aspire to include in the next version
of the product
- Break into teams
1. One BA 2. One speaks to dev 3. One designer 4. One sales or marketing person 5. Represent all the different viewpoints 6. Give them a design challenge and have them sketch out - generate -
1. Building blocks of design: square, circle, triangle, line 2. Generate ideas and pitch them: 3 minutes to present them, 2 minutes
to critique. Say 2 things that are strong about the idea and
1. Sketch -\> present -\> critique 2. -\> prototypes 3. -\> and again: sketch -\> present -\> critique 4. -\> validate 5. -\> iterate
- Get started ASAP
- Messy is okay
- Quantity then quality --> generate lots of ideas and then refine
1. Peer review then pitch -\> critique process
- Templates that they use:
1. The 685 - an "8 up template" - can put 8 sketches in there. 1. First round you do by yourself - then critique (use red and green
marker to denote what's good and what's not)
2. Second round your sketches are up on the wall
3. 5 minutes to draw 6-8 sketches
4. Can also be used as a storyboard
5. One or two rounds with 8 ups - sketching, critiquing, etc.
2. Then a 1 up
14. Three rules:
1. Know your audience and intent (are you going to give sketches to a
2. Plan a little. Prototype the rest. This guy does about
70% in sketches / planned out, then starts prototyping.
3. Set expectations - to combat questions like "why is this B&W" or "what
about the admin" etc.
15. Closing thoughts:
1. You can sketch. No BS, anybody can sketch. Anybody can
sketch, good enough to put their idea down on paper.
2. It's [sketches] not the mona lisa. Just needs to be good enough. Not
going to live forever in Moma or the Louvre, etc.
3. If you can't make it then fake it. E.g. if you can't get it to
4. Prototype only what you need. Prototype the unique parts, not
the entire system.
5. Reduce risk. Prototype early and often. Do about 2 weeks
of design studio sessions with their clients. Then they jump right
into prototyping. Then they do weekly releases. Whole agile
argument - small and rapid iterations.
"You can fix it now on the drafting board with an eraser or you can fix
it later on the construction site with a sledge hammer." - Frank Lloyd
Todd was promoting his new book: Prototyping - A Practioner's Guide - by
Todd Zaki Warfel, which I've added to my wishlist at Amazon. He mentioned that it has 6 tutorial chapters, a bit on how to sell prototyping, and some other interesting stuff.
Freeing and Visualizing Financial Data
This talk was given by Toby Segaran (@kiwitobes) and Jesper Andersen (@jandersen). They put the slides from the presentation up on slideshare. My notes:
To form a hypothesis
To tell a story
Single variable - shows you that a variable is moving but doesn't tell you why
XBRL - put forth by SEC - to put all corporate-filed reports into the open domain in an XML readable format
1. Capital IQ - data vendor 2. Requirement - in 3 years everything will have to be encoded in XML
- BSYM - Bloomberg Open Symbology
1. Unique keys of finance -\> links symbologies in finance. Problem is that different data vendors have different keys and it's a mess. 2. Competing standard is CUSIP - very expensive - but they own the data standard
- Yahoo! Finance data - downloadable via CSV - data goes back
- Amazon Web Services -> Category: Economics -> lots of data feeds
- "Trader Work Station" - some Java thing
- Freerisk - site they created