
Lessons learned from a cancelled project - bkeepers
http://opensoul.org/2014/04/28/failure/
======
jergason
I'm working on a personal project, and I find myself struggling with some of
the same problems.

1\. No constraints. Since it is just me in my free time, no one can tell me
what to do, but no one gives me feedback on what _not_ to do. 2\. No
definition of success or failure. Am I creating a product that I want to
exist, trying to polish my skills on the side, learn a new tech stack, or just
goof around? Since I can just claim that it's a hobby project when it isn't
going well (whatever "going well means"), I don't have anything holding me to
a standard, since I haven't established it yet.

Any ideas on how to avoid aimless fiddling around on personal/hobby projects?

~~~
moron4hire
I think you've answered your own question. Create constraints and goals.

Tell yourself you only have a month for the project, and you will release
whatever you have in a month. Tell yourself you will never work on new
features before fixing all open bugs. Set a goal for a minimal viable product,
set it out on paper, and promise yourself you won't do anything else until it
is met.

Sometimes, I do extreme constraints. I'll only do the project in straight
JavaScript. Or I have to draw 100 pictures, but only with one particular red
pen, and none of them can take more than 5 minutes. Or I will shoot only one
photo a day, and once I've shot a photo, I'm not allowed to shoot another. I
will type for half an hour without ever looking at the screen, no correcting
text, no revising thoughts, just half an hour of brain dump.

You learn pretty quickly how to work within your constraints. It's mostly
about eliminating distractions, and learning what sort of creative
distractions you create for yourself to make yourself feel active without
actually facing your fears of finishing.

------
e28eta
I'm simplifying it (probably too much), but those lessons seem to be some of
the things our PM brings to the team. Was this team all engineers/QA?

~~~
bkeepers
You are right. For better or worse, we have not had traditional PMs at GitHub.
Often that is a role played by what we call a PRP (primarily responsible
person). That person is often an engineer or designer.

~~~
Nacraile
> Often that is a role played by what we call a PRP (primarily responsible
> person).

So Github doesn't have managers, it just has Primary Responsible People, who
sound an awful like they do the same thing? Just don't call them "managers",
because you don't have those. Cute.

Every successful startup eventually discovers that the O(n^2) communication
overhead of a perfectly flat org doesn't scale, and needs to adapt to deal
with that. The question is whether to develop coordination specialists
implicitly or explicitly. Developing doublespeak to protect an idealistic
worldview from its incompatibility with reality does seem pathological.

~~~
bkeepers
The biggest difference is that our "PRPs" don't see management as their
primary responsibility. They're still an engineer or designer first.

> Every successful startup eventually discovers that the O(n^2) communication
> overhead of a perfectly flat org doesn't scale, and needs to adapt to deal
> with that. The question is whether to develop coordination specialists
> implicitly or explicitly.

Yep. This is certainly something we feel the pain of and are wrestling with
right now.

> Developing doublespeak to protect an idealistic worldview from its
> incompatibility with reality does seem pathological.

By definition, we don't have anyone that plays the role of "manager" right now
(again, for better or worse). I wouldn't call that doublespeak.

------
tsmith
> We eventually gained each others trust, and our visions started to coalesce,
> but only after spinning our wheels for 6 months.

> Everyone on the team suffered from burnout.

> 11 months later, our team decided to cancel the project.

My guess is that the lack of a singular clear vision caused everyone to become
disenfranchised / burnt-out in the first six months, and it took another 5
months for people to realize the project wasn't going anywhere.

I think the story underlines the importance of having product leadership -
it's all well and good to have a flat organization when the product is already
defined and the only thing left is adding features / fixing bugs (as is the
case with the github platform), but if you are starting from scratch you can't
expect a product grow to grow organically from the combined whims of
individual contributors.

> The best software comes from a team where everyone shares a vision, cares
> deeply about the result, and are motivated to make it happen.

Definitely!

> That level of caring and motivation can only come from people that had a
> role in crafting the vision and own a piece of it.

Yes, but Design by Committee is a cliché for a reason.

------
Theodores
I am waiting for some compelling work of literature to come out of this start
up culture, something with elements of 'Lord of the Flies' but more like
'Grapes of Wrath'.

If I was in start-up-central I might have to consider writing _that_ grand 'n'
cautionary allegorical tale, entirely fictional yet entirely true, with the
plot elements given here and elsewhere. Long term the right book could stand
the test of time and be around a long time after the
Twitters/AirBnBs/Facebooks have long gone.

------
rdl
Having 6 people on a project like that sounds like why it failed. If you're
not going to have a manager, one or two people seems like the correct team
size. _maybe_ 2.5 (bringing in outside design help for small parts of a
mostly-infrastructure product, or someone to do docs, or integrating with an
external system.)

------
NicoJuicy
I actually have some projects on hold, all of them seem to capture interest of
prospects. But this is the one that is not on hold and why.

\- Prospect is a client with 100 employees

\- I know the right hand of the CEO (his function is called Special
Operations)

\- They have an intern that will do data-entry for the next month

\- There was a partner meeting on 28 april to discuss the application, but
it's been delayed (Busy people over there), but all together + the webapp was
deployed 3 days before and the intern didn't had any time to manually input
data. So it's for the best

\- My expenses could all get payed (currently doing it for free, in my own
time), they should be my first big client.

\- They will have a deep integration with it (importing newsletters, ...)

\- I can sell the application to others.

All in all, what have i learned (and it has been adviced multiple times, just
experienced them in real life)

\- Get early feedback, when i first discussed the web application, i said that
i had an idea that would address his problem, i explained it and i asked him
of he could wait another month so, that i would have a early prototype with a
minimum of features. I did and he could visuallize the solution and he loved
it. 12 people in the company want to contact me (early testers), but i only
want to talk through my friend (he is the consultant in this case). He is
kinda doing the promotion for me in the company, now i think about it

\- Build fast, fail fast. A problem isn't bad, it's how you solve it. I use a
github repository to address issues. Get to know the people who have a
technical experience employed at your client. Get them to understand that not
everything will go smoothly, but you will be on top of it, if there are
problems.

\- If you're developping a webapp for other people also, you can solve the
problems like they want it to. Or you make a general solution and explain them
why. You can always find some corner cases where their proposed solution
wouldn't work or where there could be dificulties. Explain it to them! Don't
be afraid to put something on hold and prioritize your features. You only have
x hours a day :)

------
dk8996
"People matter more than product" This statement bothers me -- its not that I
hate people, I love people, but at the end of the day startups are about
products/users.

