Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Painful Lesson: Always 'Show and Tell' Your Product Before You Develop It

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Painful Lesson: Always 'Show and Tell' Your Product Before You Develop It

#61

Post by contingencies »

AlbertCory wrote: post #11

Asking people for their opinion on anything (in my case, it's writing) is an art. Not everyone's opinion is worth listening to. If you throw it out to the general public, you'll get a lot of stupid ones. It's better to pick a few people you respect, who are not uncritical lovers of your work. But you need to do that. As the creator, you have a blindness that it's impossible to get past all by yourself.

If I had asked people what they had wanted, they would have said faster horses. - Henry Ford

Speak with domain experts (people who use, provide, and repair the product or service) because it is faster than learning about the product yourself. - IDEO

... via https://github.com/globalcitizen/taoup

Re: Painful Lesson: Always 'Show and Tell' Your Product Before You Develop It

#62

Post by derefr »

SCUSKU wrote: post #49
ary wrote: post #48

A simple maxim that our investors basically demanded of us was: "Sell, design, build". Accepting that approach had two pretty noticeable benefits: 1) We didn't spend a lot of time building something nobody wanted (which is the main theme of this post). 2) We experimented a lot with our product design because we knew we'd be getting feedback quickly and thus could take interesting risks. There was little "analysis par…

How do you sell something without something to show off? For example, let's say I have an idea for an app. Naturally I would think to design a few mockups, then post it on Twitter, Reddit, etc. And then if people actually cared enough to sign up for an email list, then build. So in this case, design -> sell -> build .

1. Go to meet-ups or conferences — not for your own industry, but rather for industries and verticals that you expect to consume your product. (For example, if you're Twilio, then go to an app-dev conference.)

2. Meet people; ask what they do; wait for them to return the favor and ask what you do.

3. Pitch them on the problem you're solving — and how you are (intending to) solve it — by just talking them through it. Pretend it's something you've already built and that you're just describing the company you work for.

4. Gauge interest by who demands your business card.

Re: Painful Lesson: Always 'Show and Tell' Your Product Before You Develop It

#63

Post by AlbertCory »

contingencies wrote: post #61
AlbertCory wrote: post #11

Asking people for their opinion on anything (in my case, it's writing) is an art. Not everyone's opinion is worth listening to. If you throw it out to the general public, you'll get a lot of stupid ones. It's better to pick a few people you respect, who are not uncritical lovers of your work. But you need to do that. As the creator, you have a blindness that it's impossible to get past all by yourself.

If I had asked people what they had wanted, they would have said faster horses. - Henry Ford Speak with domain experts (people who use, provide, and repair the product or service) because it is faster than learning about the product yourself. - IDEO ... via https://github.com/globalcitizen/taoup

That's why I said it was an art.

Re: Painful Lesson: Always 'Show and Tell' Your Product Before You Develop It

#64

Post by pmarreck »

ary wrote: post #48

A simple maxim that our investors basically demanded of us was: "Sell, design, build". Accepting that approach had two pretty noticeable benefits: 1) We didn't spend a lot of time building something nobody wanted (which is the main theme of this post). 2) We experimented a lot with our product design because we knew we'd be getting feedback quickly and thus could take interesting risks. There was little "analysis par…

I guess more succinctly it would be like

1) Design mockups showing workflow for feasible idea

2) Sell feasible idea

3) Design architecture for feasible idea

4) Build feasible idea

At each new level of these you are asking more and more specific questions about how it would work and are getting "closer to the metal", with the final step being the implementation of EVERY detail (that is known, at least). Also at each step, you discover new things you didn't think to think about, but now must deal with... it's a discovery process.

But this is great because it puts the focus on "gauging interest first" before you spend weeks building anything.

Re: Painful Lesson: Always 'Show and Tell' Your Product Before You Develop It

#65

Post by ary »

haswell wrote: post #53
SCUSKU wrote: post #49

Earlier quoted context omitted.

How do you sell something without something to show off? For example, let's say I have an idea for an app. Naturally I would think to design a few mockups, then post it on Twitter, Reddit, etc. And then if people actually cared enough to sign up for an email list, then build. So in this case, design -> sell -> build .

I think this is where the difference between mockups and fully realized designs comes to the forefront. Simple mockups can communicate an idea effectively enough to sell the idea. But there’s a large delta between a pitchable mock and a design that is ready to build. Those early mocks rarely match the later designs in my experience, and I think can be kept under the “sell” umbrella.

This is the answer I would give. We did design work, but not at the fidelity that you would want to actually implement.

Re: Painful Lesson: Always 'Show and Tell' Your Product Before You Develop It

#66

Post by [deleted] »

ary wrote: post #48

A simple maxim that our investors basically demanded of us was: "Sell, design, build". Accepting that approach had two pretty noticeable benefits: 1) We didn't spend a lot of time building something nobody wanted (which is the main theme of this post). 2) We experimented a lot with our product design because we knew we'd be getting feedback quickly and thus could take interesting risks. There was little "analysis par…

[deleted]

Re: Painful Lesson: Always 'Show and Tell' Your Product Before You Develop It

#67

Post by dinkleberg »

anticlickwise wrote: post #43
reaperman wrote: post #38

Just because the people you showed it to couldn't imagine using it doesn't mean that there aren't a lot of people out there who desperately want it and would recognize its utility to them. To other creators: 0.1% of the USA and EU is 777,000 people. OP made a very niche product, hopefully he showed people who need SEO-related products, but if you only need to sell to 10,000 people to make a profit, you might "just" h…

You are right. But I must admit response like the one I got gives you a tremendous boost to the confidence. I might go back to the earlier product someday if I learn to be a better marketer :-)

FYI it is way easier to learn marketing when you have something to sell. It is very hard to read about marketing and really learn it if you don’t have a way of putting it to practice.

Re: Painful Lesson: Always 'Show and Tell' Your Product Before You Develop It

#68

Post by quickthrower2 »

chrispogeek wrote: post #30

I write the simplest incarnation of an idea onto an app, and just share it out with colleagues. I have no expectations. I'd say my hit rate is about 1/5. I consider it very high. It's also that high because my audience is my coworkers and I have a good idea of what they want. It's also that low because I just cobble together stuff that barely works, with the ultimate intent to see if i'd get more questions/requests o…

Any IP ownership issues with this? I.e. your employer claims you did it on their time?
Post reply on HN