6 ms·

When I start at step 1 with the skate board, it looks like the first part of the cartoon... 1) Build one wheel, 2) Build two wheels, 3) build connections betwee

When I start at step 1 with the skate board, it looks like the first part of the cartoon... 1) Build one wheel, 2) Build two wheels, 3) build connections between wheels, etc... (https://cdn-images-1.medium.com/max/1600/1*tcNs35GceDxSGxAaFh-lSA.jpeg https://cdn-images-1.medium.com/max/1600/1*tcNs35GceDxSGxAaF...) I don't know how this guys codes, but nothing happens all at once. -.- (am I programming wrong? Where's the magic "write code for me" button I've not found?) I think he's trying to describe "minimum viable product". (my new favorite buzz phrase, already used it with a client, and it works. No disagreements there.)

TeMPOraL 9y ago
Yeah; I'd say a comic strip like this seems useful to argue against the bottom workflow - it advocates spending time delivering 5 separate products instead of 1... But I suppose that's being pedantic :).
- RobertRoberts 9y ago
  Maybe his analogies are off, and his communication is poor. Because I agree with the idea of starting small and getting going live sooner vs later. The biggest reason for this is my clients almost universally change their mind multiple times as development goes. So instead of 100 requirements to go live, I ask them to pick the 10 most important. We go live in 2 months instead of 6, and then by month 3, 30-40 of the original requirements are dismissed as unimportant, and 10 new ones are discovered. Real world use is an incredible tool to help determine real needs of the customer vs imagined needs generated from a committee.
- kthejoker2 9y ago
  If the objective is to increase your speed, and I can deliver the 5 products in roughly the same amount of time as the 1, and each delivered product increases your speed, what's the problem, exactly?
  - TeMPOraL 9y ago
    > and I can deliver the 5 products in roughly the same amount of time as the 1 While this may work for software, sometimes, it definitely doesn't for vehicles.
JustSomeNobody 9y ago
What I think he is trying to say with the cartoon is that you should start with a "walking skeleton". Do up just enough UI, middle layer and back end to get the data going back and forth. Then start adding features, refactoring and re-architecting from there.
- RobertRoberts 9y ago
  No I get the point, but try and build a walking skeleton (ie, skateboard without first starting with the wheels/feet. If you are critical for a moment, you can see these two concepts are not dissimilar. No matter what, you always have to make the smallest part first and add onto it. Seriously, steps 1-4 building the large car are the exact same steps needed to build the small skateboard. I think he's really trying to say "lower your requirements to go live", and then from their do incremental improvements. Does that seem like a fair assessment?
  - JustSomeNobody 9y ago
    > Seriously, steps 1-4 building the large car are the exact same steps needed to build the small skateboard. They are, but the scale is vastly different. > I think he's really trying to say "lower your requirements to go live", and then from their do incremental improvements. Does that seem like a fair assessment? Sure.
  - shkkmo 9y ago
    > I think he's really trying to say "lower your requirements to go live", and then from their do incremental improvements. No, what he is saying is get your product working as soon a possible, then incrementally improve the components until you have the functionality to go live. That "go live" point (based on the smiley faces) is either the scooter (no longer unhappy) or the motorcycle (first happy face).
dchuk 9y ago
Of course you have to build things in steps. The idea is that you build something smaller/simpler first that delivers some value to the customer that requires way less steps than the complicated thing. Building a car requires many thousands of steps/tasks, a skateboard requires much less. It's easier to estimate how long a skateboard will take to build, therefore making it more likely to be done in a reasonable time, giving you the ability to give your customer a better transportation option than walking. That then buys you time to work on the next more complicated option. And so on. The other point that should be made about this process, is that it gives your customer a chance to realize they don't really need that complicated big thing. Maybe you build them the bike and they realize that's perfectly sufficient for their needs and then they just say the project is done. You'd never have that opportunity if in the same time it takes to build a bike, you're 25% done with an unusable car. Most customers vastly overestimate the solution they need. Your goal as a product manager is to build incrementally and constantly challenge the problem definition.
- RobertRoberts 9y ago
  >Most customers vastly overestimate the solution they need. Your goal as a product manager is to build incrementally and constantly challenge the problem definition. I agree, hence the term "minimum viable product", I have found this term sums up the entire argument we are all having. And I think almost everyone here is saying the same thing with different phrasing. We all know that if you want a vehicle to move you from point A to Point B, wheels are a good start, no matter the size of the vehicle or the speed required. Making the wheels bigger later to go faster just makes sense from a software perspective. And after a month on a scooter, the client may realize they don't need anything more than a scooter, and may be grateful we didn't build them a car like they originally asked for.
shkkmo 9y ago
> When I start at step 1 with the skate board, it looks like the first part of the cartoon... They key part is that that skateboard has much simpler and easy to build wheels and chassis than a car. A car chassis with care wheels is harder to build that a skateboard, and unlike a skateboard, can't actually be used for anything. If we are talking real world costs, a fully functional car wheel costs more than a whole skateboard. The point is: Don't to build individual systems one by one and wait to have a working product until every system has been fully completed. Instead, build barebones versions of the necessary systems so that you can get a working product ASAP, then improve the systems incrementally. This goes beyond just building a MVP. Instead you just build a MWP which is a "minimum working product" and iterate on it until you have built something viable. The skateboard may not actually be a MVP, you may not reach MVP until you have a bicycle or a motorcycle.

TeMPOraL 9y ago

Yeah; I'd say a comic strip like this seems useful to argue against the bottom workflow - it advocates spending time delivering 5 separate products instead of 1... But I suppose that's being pedantic :).

RobertRoberts 9y ago
Maybe his analogies are off, and his communication is poor. Because I agree with the idea of starting small and getting going live sooner vs later. The biggest reason for this is my clients almost universally change their mind multiple times as development goes. So instead of 100 requirements to go live, I ask them to pick the 10 most important. We go live in 2 months instead of 6, and then by month 3, 30-40 of the original requirements are dismissed as unimportant, and 10 new ones are discovered. Real world use is an incredible tool to help determine real needs of the customer vs imagined needs generated from a committee.
kthejoker2 9y ago
If the objective is to increase your speed, and I can deliver the 5 products in roughly the same amount of time as the 1, and each delivered product increases your speed, what's the problem, exactly?
- TeMPOraL 9y ago
  > and I can deliver the 5 products in roughly the same amount of time as the 1 While this may work for software, sometimes, it definitely doesn't for vehicles.

JustSomeNobody 9y ago

What I think he is trying to say with the cartoon is that you should start with a "walking skeleton". Do up just enough UI, middle layer and back end to get the data going back and forth. Then start adding features, refactoring and re-architecting from there.

RobertRoberts 9y ago
No I get the point, but try and build a walking skeleton (ie, skateboard without first starting with the wheels/feet. If you are critical for a moment, you can see these two concepts are not dissimilar. No matter what, you always have to make the smallest part first and add onto it. Seriously, steps 1-4 building the large car are the exact same steps needed to build the small skateboard. I think he's really trying to say "lower your requirements to go live", and then from their do incremental improvements. Does that seem like a fair assessment?
- JustSomeNobody 9y ago
  > Seriously, steps 1-4 building the large car are the exact same steps needed to build the small skateboard. They are, but the scale is vastly different. > I think he's really trying to say "lower your requirements to go live", and then from their do incremental improvements. Does that seem like a fair assessment? Sure.
- shkkmo 9y ago
  > I think he's really trying to say "lower your requirements to go live", and then from their do incremental improvements. No, what he is saying is get your product working as soon a possible, then incrementally improve the components until you have the functionality to go live. That "go live" point (based on the smiley faces) is either the scooter (no longer unhappy) or the motorcycle (first happy face).

dchuk 9y ago

Of course you have to build things in steps. The idea is that you build something smaller/simpler first that delivers some value to the customer that requires way less steps than the complicated thing. Building a car requires many thousands of steps/tasks, a skateboard requires much less. It's easier to estimate how long a skateboard will take to build, therefore making it more likely to be done in a reasonable time, giving you the ability to give your customer a better transportation option than walking. That then buys you time to work on the next more complicated option. And so on. The other point that should be made about this process, is that it gives your customer a chance to realize they don't really need that complicated big thing. Maybe you build them the bike and they realize that's perfectly sufficient for their needs and then they just say the project is done. You'd never have that opportunity if in the same time it takes to build a bike, you're 25% done with an unusable car. Most customers vastly overestimate the solution they need. Your goal as a product manager is to build incrementally and constantly challenge the problem definition.

RobertRoberts 9y ago
>Most customers vastly overestimate the solution they need. Your goal as a product manager is to build incrementally and constantly challenge the problem definition. I agree, hence the term "minimum viable product", I have found this term sums up the entire argument we are all having. And I think almost everyone here is saying the same thing with different phrasing. We all know that if you want a vehicle to move you from point A to Point B, wheels are a good start, no matter the size of the vehicle or the speed required. Making the wheels bigger later to go faster just makes sense from a software perspective. And after a month on a scooter, the client may realize they don't need anything more than a scooter, and may be grateful we didn't build them a car like they originally asked for.

shkkmo 9y ago

> When I start at step 1 with the skate board, it looks like the first part of the cartoon... They key part is that that skateboard has much simpler and easy to build wheels and chassis than a car. A car chassis with care wheels is harder to build that a skateboard, and unlike a skateboard, can't actually be used for anything. If we are talking real world costs, a fully functional car wheel costs more than a whole skateboard. The point is: Don't to build individual systems one by one and wait to have a working product until every system has been fully completed. Instead, build barebones versions of the necessary systems so that you can get a working product ASAP, then improve the systems incrementally. This goes beyond just building a MVP. Instead you just build a MWP which is a "minimum working product" and iterate on it until you have built something viable. The skateboard may not actually be a MVP, you may not reach MVP until you have a bicycle or a motorcycle.