The key to iterating isn’t chopping the work by time (eg 2 week sprints). Chop it by interdependence. Then you can get one orthogonal piece “done” top to bottom early on and move on to the next thing. Far more satisfying than hoping to integrate everything in the 11th hour.
-
Show this thread
-
Deeper point: chop the work vertically, not horizontally. Instead of “design” and “programming”, integrate a little design and a little programming into, for example, an “inbox view” scope, and get that done.
8 replies 14 retweets 84 likesShow this thread -
Replying to @rjs
Even better: instead of integrating efforts around time ("2 week sprint") or feature creation ("inbox view") consider integrating around the generation of a specific user outcome instead.
1 reply 0 retweets 5 likes -
Replying to @SamuelHulick
Yes that’s at a higher level. You still need to break down the work into “what am I working on today” and that’s going to be more about the anatomy of the implemention than the user outcome.
1 reply 0 retweets 7 likes -
Replying to @rjs
I hear that for sure -- at some point you have to make SOMETHING, right? That said, though, I'm curious about the relationship of the "higher" and "lower" levels you're referring to: 1/2
1 reply 0 retweets 1 like -
Replying to @SamuelHulick @rjs
If our product features are ultimately only as valuable as the user outcomes they contribute to, how do you derive lower-level considerations from higher-level ones? e.g. At Basecamp, how do you determine whether the "what I'm making today" actually produces value for the user?
2 replies 0 retweets 2 likes -
Replying to @SamuelHulick @rjs
Would both of you be willing to come on our podcast and talk/debate? Enjoy following your different opinions on Twitter. How about something higher bandwidth?
4 replies 1 retweet 23 likes
Seconded on the enjoyment.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.