Whiteboard Recap #6 – Design Workflow

Leave a comment

Joe, our UX team, walks through how we broke down our most complex component from a design perspective, and the recent work we’ve done on identity and branding.

Also noteworthy, plaid is now the official uniform of OnCompare.

Whiteboard Recap #5 – Scope Creep comes to visit

Leave a comment

This recap is all about how our good friend “scope creep” came to visit over the weekend.

He was trying to convince us we needed to incentivize community involvement, which he convinced us of, but only after we cut a number of other stories. At the end of the day, we didn’t add too much work to our plate, but there’s a little.

Bonus: some mildly NSFW language near the very end!

Whiteboard Recap #4 – History of OnCompare

2 Comments

While we’re building OnCompare over the course of three weeks, the idea behind it, and customer development on it, started a couple months back.  In this video I talk a bit about what came before 3 Weeks to Live.

Zenboard Recap #3 – Prioritizing too much work w/ AgileZen

5 Comments

Mixing it up today with a zenboard, instead of a whiteboard, recap.  We thought it would be interesting to talk about how we’re defining our stories (short answer – poorly) and how we’re prioritizing what will ultimately be too much work.

Quote of the video, “it’s a placeholder for a conversation.”

Also in this video:

  • A glimpse of AgileZen in action. It’s a terrific, lightweight SaaS tool for agile project management.
  • Proof that my Aaron impression yesterday was spot on.

What project management tools do you use?  Maybe we’ll take everyone’s recommendations and make a website that compares them all.

Whiteboard Recap #2 – Requirements & Workloads

3 Comments

I’ve got good news, and bad -

Bad news: we didn’t capture the audio when we recorded this recap.
Good news: you get to hear my (almost) spot-on impression of Aaron.

Requirements

Today’s recap is all about where we derived our requirements for this version of OnCompare. Like any good lean startup, we’ve derived our requirements straight from our hypotheses.  We have ideas on how we can:

  • Monetize
  • Incorporate marketing into the product
  • Create a defensible business
  • Provide useful recommendations

but we won’t know until we test them.  That’s what these three weeks are all about.

Workloads

Aaron also described how we approached assigning work across the team and how that quickly evolved.  We started by assigning core components of the project to each engineer but quickly realized that wasn’t going to work:

  • The core components were vague and writing up huge specs to define them isn’t a good use of our time.
  • The core components were vastly different in size & scope, meaning we could easily create an imbalance in workloads.
  • Vague tasks invite scope creep – public enemy #1 of this project.

Instead we focused on “stories”, identifying bite-sized chunks of user-oriented functionality that devs would self-assign.  This model:

  • More efficently distributes the workload
  • Promotes communication, collaboration & integration (since you’ll often be working on two different components in the same day)
  • Encourages cross-pollination of knowledge
  • Builds in “backup” devs for all components.  If someone hops off the project, there’s little chance his work will have been silo’d – someone will have enough knowledge to carry the torch in his stead.

There you have it – that’s recap #2!

Whatcha think?  What problems are we going to run into with this model?  What would you, or have you done in similar circumstances?

It’s not too late for us to change!

Whiteboard Recap #0 – Product Design

3 Comments

When I asked friends what we should put in this blog, one of them had a great idea – recap what we whiteboard each day.

Since whiteboards are hubs for brainstorming, collaboration and making critical decisions, I thought it was a great way to document and share.

This first recap covers the evolution of OnCompare’s product design.  Customer development helped us identify and validate a pain point – product design process is all about how we’ll try to alleviate that pain.

Follow

Get every new post delivered to your Inbox.