
Thirty Percent Feedback - jaf12duke
http://blog.42floors.com/thirty-percent-feedback/
======
derefr
I think that even at the 90% mark, there's value in giving what I would call
"craft-work feedback": the type of feedback one craftsman gives another.

 _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.

~~~
robomartin
Engineering, to some extent, requires mastering the art of knowing when to
temporarily abandon a project in the intest of shipping. A mature engineer has
gone through this cycle multiple times to the point that the "abandon to ship"
concept becomes part of his/her normal process. It's far too easy to keep at
it and never ship anything.

------
munificent
> Often times, when I seek feedback on a project, it’s not actually
> constructive feedback that I want; it’s simply approval. I want a pat on the
> back and a “job well done.”

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/issues

~~~
teach
I've found the same thing to be true with my book.

------
clarkevans
Asking what kind of feedback you wish to receive (or are asked to give) is
important.

When 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.

------
zaidf
Has anyone else found themselves on the extreme end of focusing too much on
shipping quickly? One of the realizations I had this year was that in the
process of wanting to ship quickly, I'd started doing mediocre work. More
recently I have been encouraging myself to take whatever amount of time it
takes for me to build something I am at least a bit proud of. Sure I don't
want it to take any more time than necessary; but I also don't want to be
shipping things consistently that I am far from proud of.

~~~
dsugarman
If you release something that you are far from proud of and have users, I
guarantee you will know what to build or fix next that will most improve your
feature for your current user base. That is not something you will have if you
didn't ship first

~~~
zaidf
Totally. Though I took stock of all my projects in the last 15 years, and
almost every single one of the projects that I launched for the sake of
shipping quickly failed. The ones that got traction are ones that I spent a
lot more time(and emotion) towards.

~~~
ianstormtaylor
This is something I struggle with thinking about too as the founding designer,
and generally most quality-driven person, at our company. The simplified
version of the spectrum as I see it is:

    
    
        1. Shipping quickly with a shitty solution.
        2. Shipping slightly slower with a polished solution.
        3. Shipping very slowly because minor details took over.
    

The frustrating thing is I can generally feel the difference between #1 and #2
myself, but I'm not sure how to distinguish between #1 and #2 enough to argue
my point to the rest of the team. Instead I usually have to result in vague
responses about quality and reputation and such, or just go into the UI or
codebase and tweak things myself.

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.
    

Instead we spent that time making sure the core form in the product was as
helpful and simple to understand as we could make it. There was an animation
that we added when turning an integration on that was completely unnecessary
from an MVP standpoint, but it was one of those quality things that made it
super obvious how the form worked, and added a touch of polish to the product.

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...](http://feltpresence.com/articles/9-what-happens-to-user-experience-
in-a-minimum-viable-product)

[2]: [http://feltpresence.com/articles/18-ui-and-
capability](http://feltpresence.com/articles/18-ui-and-capability)

~~~
zaidf
_the way you reduce time taken to ship a feature is to drastically cut scope_

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.

~~~
ianstormtaylor
That's a really good point about passive time before the actual building. We
had definitely been thinking about the problem for a while, and
analytics.js[1] had already existed for at least 6 months in its current form
and another 6 months in a prior one.

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](https://github.com/segmentio/analytics.js)

[2]: [http://www.myth.io/](http://www.myth.io/)

[3]: [https://github.com/ianstormtaylor/rework-pure-
css](https://github.com/ianstormtaylor/rework-pure-css)

------
chavesn
I worked at a place where we tried practicing the principle of the 30% demo.
We had one additional point -- at 30%, you should have rough "end-to-end"
progress.

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.

------
romaniv
_When someone takes way too long to get a first draft out because they’re
being perfectionists and you praise them for their quality craftsmanship_

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.)

~~~
wpietri
Totally depends on the person. You rarely see the work of those people because
they never get anything out the door.

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."

~~~
romaniv
_Totally depends on the person. You rarely see the work of those people
because they never get anything out the door._

How can a developer get _nothing_ out of the door without eventually getting
fired? I honestly cannot imagine an environment that would allow this.

~~~
wpietri
"Never" was hyperbole.

------
Duhck
Ive been doing this with my own startup. I am about 30% there (regarding
talking to investors about it) and as such I have reached out to investors I
am friendly with and asked for feedback.

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.

------
gk1
There are two skills at play here:

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](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.

[1] [http://www.gagcartoons.com](http://www.gagcartoons.com)

------
rayiner
This is really great. It's really easy to disincentivize the right behavior.
If you point out every typo in a first draft, then people aren't going to let
you see work that's not "90%" done, even if you tell them to bring you a "30%
draft."

------
pcurve
This is the most clear piece of writing I've read in awhile. No fluff. No big
words. Clear sentences. And great content. Thanks,

------
pranaya_co
Jason brings up a very good point. Especially the first part (where people
tend to dislike tough criticisms) resonated very well with me because - my
startup, StartUpLift.com - specializes in providing crowdsourced feedback to
startups. One of the features that we offer to startups is that they can
reject any feedback / feedback provider at no cost to them. It's interesting
to note that more than 65% of the rejection happens when when they get some
sort of negative feedback, which in fact is a disguised constructive
criticism.

------
001sky
This is a great post. There is alot of value added to getting feedback before
the "proof-reading" stage. What is harder perhaps in this equation is finding
the time, the person, and the structure to provide you this feedback. But it
is in the "30% done stage" when even a small amount of astute input can have a
huge productivity benefit. There is a real art to getting something in "good
enough shape" to be interesting for the reviewer (ie, not wasting their time),
and thought through enough so that the important tensions & dynamics are able
to be shown in rough-hewn relief (ie, so the analysis is also useful to you).
I'm a firm believer that this is a great place to have a mentor (or, if it
fits your fancy better... a muse). And also successful people are often
blessed with having this type of support infrastructure in place. It really
helps to build depth into the work, in a way which is different from pure
"hyper-focus". The can counter the trend toward narcissism and lessen the
tendency to attribution error.

------
philbarr
I think developing a thick skin is most important when asking for someone to
review your work. I don't have any developers locally that I can ask to look
at stuff, so I'm never going to get a professional point of view.

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.

------
tpdubs2
Dead on. I used to this model to edit student and colleagues' work for years.
Impt to note is that it's a huge time investment to give feedback for the 30%
part. I want to know from the start what the person wants, so that I don't
invest time and energy into a project when he or she really just wants a copy
edit. This model is a win-win for both sides.

------
davidjgraph
Good advice, but seems like a long way around saying "do everything in small,
fast iterations, including research"...

~~~
sp332
It's more specifically about getting pride out of the way, which is a
necessary first step.

~~~
jtoeman
bingo.

------
alexobenauer
We do this all the time at Mindsense. It's a great way to go about giving and
asking for feedback.

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.

------
mathattack
Giving and receiving feedback is one of the hardest things to do in a company.
(Or relationship) There are books about it, there is training to do it, but
sometimes it still just doesn't work. As such, most managers shy away. I will
give this a try.

------
josefresco
Off topic but what is the HN "share" icon on the right sliding box supposed to
show? Up votes or submissions or comments? It's reading 0 right now so either
way it doesn't seem to be working (unless it's just me).

Anyone have an idea?

~~~
aroch
It would appear upvotes: [http://www.hn-button.com/](http://www.hn-
button.com/)

------
jdavis703
Practical application: when I work on a large new feature I will often create
mini pull requests to gather feedback on a few hundred lines of code and then
merge them into my feature branch, which may be thousands of lines.

------
shurcooL
This is good insight, and it's precisely the problem I'm starting to see with
GitHub repos. People have no easy, standard, way of telling if a given repo is
30% complete or 90% complete. :/

