Live data from Hacker News

Walking Away from the Product I Spent a Year Building

derrickreimer.com

71–80 of 221 posts

Re: Walking Away from the Product I Spent a Year Building

#71
post #4

"The gist is that it’s tough to get unbiased feedback during customer validation." - I wish this was taught along with lean startup content. Too many times I have heard founders say they validated the idea when all they have done is gotten biased feedback while asking self-fulfilling questions.

Yep, it is extremely hard. Lean Startup makes it sound trivial when it's almost impossible. Almost nobody is going to clear up their day to talk to you about their problems, answer your questions, give you feedback, be your guinea pig, etc. The ideal way to validate it is to be so immerse in the industry/problem such that you understand most of the pain points. Do the job that your ideal customer is doing. Attend the…

Sure people will give you their time. It's very simple to get. Pay them.

It's called an inducement for a reason.

Too many "product people" or "visionaries" or whatever just don't know how to do user research and validation.

Too many people also have no idea how to solicit unbiased feedback and too many rely on asking questions and not nearly enough observation or testing.

Re: Walking Away from the Product I Spent a Year Building

#72
post #47
post #21

Earlier quoted context omitted.

I am a product manager and basically live in slack. My job is basically to communicate all day. On the flipside I've spent the last couple years learning to code in my free time and I can't imagine being interrupted by slack while im in a groove. It's def made me better about waiting to talk to my devs in our daily meetings despite being right next to them

Paul Graham's essay "Maker's Schedule, Manager's Schedule" should be required for anyone working with developers. http://www.paulgraham.com/makersschedule.html

Thanks for recommending that, well written and gives clarity to something that can be a source of misunderstanding and friction.

Re: Walking Away from the Product I Spent a Year Building

#73

"Every large team I spoke to had an exceptionally high bar and was unwilling to entertain Level until it was significantly more “mature.”" They all made the right decision, as it folded only a couple months later.

I don't think that's the kind of "mature" they were talking about. From context, I think it's pretty clear they were thinking about product maturity. If customers are suspicious of organizational stability, they use a different set of excuses. E.g., they'll ask about funding, large customers, track record.

Re: Walking Away from the Product I Spent a Year Building

#74
I built and ran a groupware/crm system from 2001 to 2009. But didn't get the traction I needed and couldn't afford the co-located hosting any longer. I spent 3 years developing it full-time myself and very part time on it the rest of the time. While also supporting a wife and two kids.

I moved it to very cheap hosting, told everyone it was closing, but then never closed it but didn't accept new signups. Checking now there is still a little usage in 2019 (although the majority of usage stopped in 2016).

It costs me $20 to keep alive, using GoDaddy. It was $14 a month but GoDaddy keeps raising their hosting price with no notification.

Eventually I will re-design the UI to Boostrap to make it modern and relaunch it.

What I am trying to say is if you made something nice that you like, you can keep it alive and work on it sometime in the future. You never know when Slack is going to bought out and then eventually die. You could be the DuckDuckGo to Google but for Slack. If you had a million dollar marketing budget things would be different.

Re: Walking Away from the Product I Spent a Year Building

#75
post #50

Earlier quoted context omitted.

Not necessarily true. For example the enterprise I work in doesn't allow saving chat history. This makes email better for technical discussion that needs recorded.

What's the rationale behind that?

Legal. When we are sued (we make equipment used in dangerous environments, and we have a lot of money, so if there is the slightest chance we can be blamed we will be sued) US law says we need to give all relevant information to the other side. That includes any saved chat logs and emails. However if something was deleted before we are sued we don't have to give it out.

We lost a law suit once because a [not native English speaker] wrote "the bearing will fail with disastrous consequences", he meant the shaft would need to be replaced, but when a fire started in the area of the bearing that email was part of discovery and the jury decided the bearing was at fault for the fire not the user failing to clean the area which was our story. (legal would rather I not give you the case to read for yourself)

Chat tends to be less formal than email, thus more opportunity exists for something that is easy to take out of context. By not allowing saving chat logs we ensure they they will never get to court.

We have strict rules that emails must be deleted after a few months (unless we legally need to keep them). Any information in the email that is worth keeping longer than that is put in a formal system where legal can examine the words to ensure they won't be taken out of context and used against us.

Re: Walking Away from the Product I Spent a Year Building

#76
I've been listening to The Art of Product podcast since the start and Level really didn't make sense to me as a solution even though I understood the problem.

Most issues are around context and focus when moving from an individual contributor to a lead. If a programmer I'm leading doesn't implement a feature in a way that I expect it is because the context that is in my brain hasn't been transferred to the programmer's brain. If a feature isn't being worked on then I having communicated focus and priority.

A solution would focus on revealing context and focus by:

1) Deeply integrating with Slack, JIRA, Github, etc. The tools that we already use. A new product can't be a silo.

2) Mobile or GTFO. Leads are in meetings, on airplanes, in transit, etc.

Re: Walking Away from the Product I Spent a Year Building

#78

Earlier quoted context omitted.

That kind of circular reasoning is only more maddening because it makes sense. It is a self-fulfilling prophecy combined with a prisoner's dilemma.

It also requires time travel to implement; the folding knowledge was not known at the time of decision.

You don't need a time travel device, just a bayesian prior on probability of folding. (which happens to be close to one.)

Re: Walking Away from the Product I Spent a Year Building

#79

Earlier quoted context omitted.

I say it every time, to every founding team I meet. Read “The Mum Test”[1]. It will make you aware that you to get unbiased feedback you need to remove your identity from the idea so that people aren’t nice to protect you. [1] http://momtestbook.com/

I also keep recommending this book to everyone. The TL;DR is: NEVER ask questions about hypotheticals. Ask people about what they do, how much they pay, how much time it takes, and so on. Facts, not answers to "Would you use this if...?"

Indeed! One of the things I found frustrating about the article is that he talks about people 'lying' constantly... when if fact he had just asked meaningless questions.
Post reply on HN