Thirty Percent Feedback
blog.42floors.com
blog.42floors.com
First, you tell them that, from the perspective of the end-user, their craftwork is done, and nobody will notice anything wrong with it. It's shippable. It's usable. They probably won't hear one complaint, and sales will be good.
Then you point out the little things. The things that only other craftsmen will notice, but that end-users, despite not knowing to look for them, would still appreciate if you changed. The things that would take the thing from "done" to "perfect." The things that are, to most craftsmen, "just a matter of pride."
But you must finish off by reminding them that since they have a deadline (and they do, even if they call it "runway"), it's not even a matter of fixing all the little things. They don't have time to fix all the little things. Instead, it's a matter of picking the highest-impact ones they can fix in the time available, fixing those, and then shipping.
I think the key insight from such an explanation is that there are always some issues you point out that they must simply "accept": it's wrong, and now they're aware it's in there, but it's not going to get fixed, and it's going to ship like that, and everyone is going to see it (though only other craftsmen will notice it.) Tell them that they can't be paralysed by this thought: instead, they must accept it, learn from it, and do better with the next one.
I think creative people want and need both. I spent a lot of my free time working on a non-fiction book[1]. I'm really aggressive about soliciting feedback: every page of the book links directly to its issue tracker on github[2].
I love critical, detailed feedback. I want my book to be great, and I can't improve the clarity of my writing without people telling me, "this was confusing" or "this was boring". Bug reports fill me with joy.
At the same time, though, the reason they fill me with joy is because they make the book better. And a big part of the reason I care about making the book better is because it means I get more approval, more email patting me on my back.
I'm fortunate enough to also get positive feedback, comments from people that say nothing more than "You're doing a great job!" That isn't actionable feedback, but if I didn't hear those kinds of comments too, I wouldn't have the motivation for the feedback that is actionable.
[1]: http://gameprogrammingpatterns.com/
[2]: https://github.com/munificent/game-programming-patterns/issuesWhen asked for feedback on a 90% completed project you simply shouldn't comment on the big picture, that's set, the feedback is about what small, tactical changes can be done to improve the invested effort. While at 30% things are more strategic... are you missing an essential part? can it be restructured?
I think this post exactly encapsulates the pattern my wife and I have settled on after 15+ years of lively (sometimes embittered?) discussion. Now, we've learned to always ask: "are we editing, or scoping", or "tactical or strategic"? Asking what sort of feedback someone is seeks is essential to non-frustrating communication and having your review received properly -- in a manner that is actionable.
1. Shipping quickly with a shitty solution.
2. Shipping slightly slower with a polished solution.
3. Shipping very slowly because minor details took over.
But on the flip side, I also know that I bring up issues that, at first glance, I think are must-haves for quality, but really aren't. Instead the scope should be decreased not to include the feature at all. But my credibility each time I bring up something like that is diminished, rightfully so.
I often struggle with this when giving friends advice about their MVPs too. Everyone has gotten so wrapped up in MVPs and they equate the MVP to throwing quality out the door, but MVPs are much more about throwing away scope in my opinion. I actually think quality can actually break or break an MVP, but it's hard to convey this properly to non-design-focused founders because they might not see the difference between certain purely-aesthetically-driven decisions and the more general and important product-quality driven decisions.
We built the Segment.io MVP in two days, but we did it by cutting scope, not quality. We didn't have a settings page, a way to delete accounts, a way to reset passwords, a way to invite teammates, anything that seems like it's necessary to work on a project. We literally had:
1. A junky home page.
2. A login page that literally just two inputs and a submit button.
3. A signup page that was similar.
4. *The* product page that was a glorified settings form.
Obviously this is completely anecdotal, so I have no idea what would have happened had we went the other way, but I do really think that some of the things we spent time getting right had an impact on our user's perceived quality of the launch. I'm not sure how successful we would have been had we not done that.
There's a really good article[1] by Ryan Singer (from 37signals) on this topic that argues that it basically boils down to scope. And we've found this to be really true for ourselves while working on Segment.io. Basically you go with the designer's (or close to it) opinion on what quality should be, and the way you reduce time taken to ship a feature is to drastically cut scope. It sounds way easier than it is, but I think finding ways to cut scope is easily one of the top 5 things I've learned since starting the company.
And Ryan also has another good article[2] about how to cut down on design time by focusing on capability instead of styling. I think he's right there, style in the early stages (while important from a first experience point of view for your users) only need to be "good" not "great". Basically most designers can pretty easily decide on a style pretty quickly for an MVP and then execute on it, whether it's amazing or nt. But capability should be paid more attention to because that is where things like "did this solve my problem?", "do I want to share this with my friends?", etc. come into play more.
I don't know if that helps at all, but I'd definitely love to read more people talking about this.
[1]: http://feltpresence.com/articles/9-what-happens-to-user-expe...
That's such a great way of putting it! I think what makes this difficult is that it is hard to come up with a formula - so much of it is a "feel" that you develop over years of doing it.
Also, in tech we often account for the development time but not as much the time for everything else. Even though segment.io took you two days to build the MVP, I have a feeling it took you many, many more "passive" hours of thinking about the problem(may be even before you decided to turn it into a startup). When you take that into account the time you spent experiencing the problem and thinking through the various solutions, the MVP took you a lot more than 2 days to build.
One of my most successful projects took me barely a day to code. But it was a painpoint that I experienced and thought about pretty much every week of my undergrad. But for some reason, I did not feel I was in a position to attack the problem until a very particular moment. I'd like to think that if I attacked the problem the very first time I had the inkling of the pain, my solution may have been very different and less likely to gain traction.
It just takes a while to start developing solid, bigger-picture ideas about a problem. This is also why it's hard to realize the negatives of "pivoting" all the time, since we take for granted how much we've already invested in groking a particular space.
The same thing happened recently while hacking on Myth[2]. To everyone on the team it felt like building the entire thing only took a couple days, but really I had been experimenting with a similar idea[3] for multiple months, and it was already being used in production for our own CSS. The piece that took a few short days was just figuring our the best way to design the landing page—much less scope that conceiving the entire idea.
It's really hard to quantify that kind of time investment, and even harder to explain that to friends who think that everyone is launching fully-formed, successful MVPs in a single weekend without much thought. It definitely seems like something that can only be learned through experience. It's just an earlier stage version of the classic problem of founders always thinking that successful startups spring out of nowhere, when really the multiple years of living in a cramped room and almost killing each other is just shielded from view.
At least it makes things more defensible :)
Random other thought: I often catch myself bundling up tons of logic into a "first commit" and wishing that that wasn't a common practice, so that we could learn about how the beginnings of codebases are iterated on.
[1]: https://github.com/segmentio/analytics.js
[2]: http://www.myth.io/
> 3. A signup page that was similar.
I don't think I'd be amiss in pointing out the login page of the site we're using right now, which has one page with both of those forms in exactly that format. :)
This made a drastic difference in how early we were able to assess a design direction. Previously we would have only made 30% progress but that 30% would have been polished. Making it an "end-to-end" demo allowed us to get that kind of rough feedback on the whole feature. And if we needed to, tuning our direction at that point wasn't that painful.
The result was that we no longer had to throw away work that was polished but didn't deliver the goals we wanted -- or worse, continue to force the path because of sunk cost bias, ignoring the feelings that something wasn't right.
Does that ever happen in real life? I don't think people need any more encouragement to praise speed. Speed is already valued an order of magnitude more than quality to the point where it is the only thing that's looked at. (In part that's because speed is easier to measure and show on a chart.)
If you're familiar with the Dunning-Kruger effect, it's the flipside of the fools who don't know how little they know and ship garbage. The people who are strongly aware of how little they know may never ship anything.
Ira Glass puts this well: "Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through."
How can a developer get nothing out of the door without eventually getting fired? I honestly cannot imagine an environment that would allow this.
Note that you don't always have to be always right(meaning that feature you thought was really needed does not have to take off) but you do need to constantly calibrate your judgement so you get a feel for the type of intensity any given problem requires.
Most of the feedback I have received was "you are about 25% there" which validated my assumption of not quite being ready to approach people for money, and it has allowed me to refine and adapt my pitch accordingly.
It was much easier to get feedback from people when I told them I was just starting out, instead of telling them I am ready to receive money. This opened them up to positive and constructive feedback that is helping me get closer to my goal.
1. Asking for feedback in a way that will result in a constructive response
2. Accepting constructive feedback
Just a few days ago I asked people to rip apart my consulting page [0], and I received a handful of truly excellent feedback; some positive, some negative, but all were constructive.
[0] https://news.ycombinator.com/item?id=7269069
PS - Glad to see you're using a gag cartoon instead of just a stock image. For anyone else wanting to do the same (it gets more engagement than stock photos), I run a side project that helps you find and license these cartoons easily and cheaply [1]. I know Jason Cohen (of WPEngine) uses similar cartoons.
Instead I just ask friends / family / people I meet in the pub to review an app and sit back and listen. Since these are "normal" people, a lot of them will be put into the mindset that you're trying to show how clever you are because you wrote an app and will instantly try and find every little thing wrong.
You have to just sit back, nod and smile, say thanks, and then pick through the feedback looking for the important bits.
In fact I believe this is a generally useful life skill. Try and listen to everyone, even if you think they're completely nuts, and sieve out the decent remarks without ego. It's not easy but I think it's important to practise.
Whenever I'm asked for feedback, I first provide only high-level feedback about the direction of the work, ignoring little things like sentence structure. I then say when they are ready for the typos and grammars feedback, let me know.
Anyone have an idea?