4 ms·
I think there are probably two schools of thought here. Steve Barsh argues you need to define your customer, their problem, and your extremely compelling soluti
by JacobAldridge 18y ago
I think there are probably two schools of thought here. Steve Barsh argues you need to define your customer, their problem, and your extremely compelling solution, then code.
PG tends to argue the other way - code first, release early, GET USERS, and then have them define the solution they need.
Working with a number of businesses I don't think there's a right or wrong. The risk with Steve's method is inbuilt assumptions you can make answering his questions, long before a real person ever sits in front of your program.
- webwright 18y ago"The risk with Steve's method is inbuilt assumptions you can make answering his questions, long before a real person ever sits in front of your program." Not really risky if you iterate this the same way you iterate software.
- jon_dahl 18y agoAt the risk of sounding inane, you have to do both. Iterate, release early, and listen to users (PG). But also think deeply about the market, how you differentiate yourself, how you'll get the message out, and be sure you're really building something worthwhile (SB). Both contribute to the same goal - figuring out what your product or service will look like - but they attack it from different sides. No reason why you can't do both. But if you naturally lean in one direction, you might want to be careful that you don't ignore the other.