322 karma · joined October 19, 2007
I do believe you want to pick "valid" anchors and sometimes be more selective (as-in the iPad case) but the comparison has to stick.
Yes, pricing is a conversation but you need to lead the conversation because if you pause and think about it, there is no rational justification for your customer to offer you a fair price.
They are either clueless on value and don't know OR they'll low-ball you because they want a good deal.
"The fair price for your product is usually higher than what both you and the customer think".
I don't believe customers hold all the answers and the point of this post is that you can't be complacent about finding and testing that path to customers.
Customers are great at articulating problems but whenever they start suggesting solutions, I try and get to the root problems whether it's before Version 1.0 or a feature request after.
Before launch I do talk to customers - the first is an interview, second is for feedback. The interview is to learn about problems and how they solve them today (existing alternatives).
Armed with that knowledge, I then build a "demo" (prototype, mockup, etc.) that I show to them once more to validate this "will" solve the problem before I build the real product/feature.
For a more detailed write-up: http://www.ashmaurya.com/2011/07/how-we-build-features/
- Ash
The book isn't a lead-in to LeanCanvas and I was/am conscious about not making the example in the book self-promotional. I wanted to pick a "real" example to which readers could relate and one that I had recently built. The software would most likely be bundled with the book. As a standalone it wouldn't cost $49/mo but more like $14/mo (still early to tell).
Thanks for the SEO tip.
The structure is something I've struggled with. There is certainly a battle in my mind between a chronological presentation of "the methodology" and building sufficient background context.
This is the first structure that made sense but your comments of poor navigation and too much summarization are right on. I will try and find a better flow for the next iteration.
Parts 2 and 3 are still being written. I wanted to put out what I had so far and really appreciate the detailed markup you did on crocdoc.
"...what I found in our case was that trying to educate people on how our product worked differently was a loosing battle. Telling people they could share their photos and videos instantly and without any uploading usually resulted in one of 2 reactions. They either got confused or didn’t believe us. We instead decided to focus on a more general “finished story” benefit and ushered the user to experience the product for themselves."
Granted our audience is typically less technical, but this was the case even with technical folks when I described the service to them.
The "personal" picture over a screenshot tested a lot better and has worked for us.
Thanks.
My interpretation of this process for a Web startup is getting to transition using just the founders (plus advisors).
Once you have product/market fit, you have the semblance of a business. You transition towards growth from there.
I agree real-time tweets would be too spammy (unless you have a twitter account just for releases) but a community forum might be better for immediate announcements.
Our goal was not to work AdWords to pull bunnies out of it, but rather to drive a little targeted traffic so we could test. We got much more utility out of usability testing and talking to real customers. I also think there is a lot more low lying fruit to be picked before resorting to working AdWords.
Thanks for the comments.