Ask HN: How do you tone down your idea to something fesible? | Hacker News Reader

Ask HN: How do you tone down your idea to something fesible?

10 pointsdiminium19 comments

How do you guys tone down your ideas to make something feasible but still relevant?

Sorry, I don't have time to make this short.

There are 2 ways:

1. Talk to individuals who you expect to be your users.

Ask them how they currently do what your idea makes easier to do. Try to find out if they have any problems with it, but don't push too hard. Just listen. If they seem at all receptive, tell them about your idea. Then pay attention to everything they talk about (good or bad). If they don't seem interested at all, move on. Find the next person to talk to. Your aim at this stage is to find people who do think your idea has some value. The uninterested ones provide data to act on in case you don't find anyone interested in your idea at all.

If you can find even 1 or 2 people who love your idea and really get excited about some feature, then build that as quickly as you can and get them to use it.

2. Just build whatever little thing is useful to you immediately. It's ok if it's ugly and incomplete. It should just give you more of at least one of the following: time, money, fun, happiness.

Then show it to other people who you think might like it. Most reactions on design you can safely ignore. People have a natural tendency to talk about how things look because it's what they see first and feel obliged to say something. It happens on HN all the time.

What you want to look for is things people really love or hate about what the thing does. Also look at the data on what people are actually doing with your product. They often say one thing, and do something completely different. So pay attention to actual behaviour.

Out of all of this, you might notice one or two things really stand out. When they do, zoom in and focus on them to an extent that will seem ridiculous. It should make people say things like "This is just a feature, not a product". Then you know you're really onto something.

The more interesting and novel your idea, you are better off going with route 2. The new conventional wisdom (of Lean) suggests you should mostly always go with 1. But if you look at the landscape, the best ideas come from 2. The chance of failing may also be higher with 2, but that's where the artist in you comes out and pushes the boundaries.

Talking to people about your idea too early may kill the spark of magic that brought it to life. Make it real asap.

These gentlemen say it better than I can - http://www.zefrank.com/theshow/replay/?p=363

http://www.thisislondon.co.uk/lifestyle/london-life/sir-jona...

You nailed it. Either way, I think the most important thing is to go out and talk to people. Our mental models are pretty limited in that we see and feel what we wish to see and feel. Talking to people helps open up whole new ways of looking at things. There's always another perspective you failed to see.

I recently came across the Stanford design Bootcamp Bootleg [1]. It outlines the whole process for getting from an itch to a working product. And they obsess over empathy. It's all over the Bootleg. Interview potential users, learn how they currently solve the problem you're trying to solve and show them how your idea could help them.

The Bootleg is highly recommended. Even if you don't follow the practices it describes, it pays to have those mental models.

We were brainstorming recently. And we did this entire exercise. We went to meet students, shop owners, teachers and even some folks at the local administration. It was extremely tedious but our efforts paid off. We gathered insights that range from pretty obvious to mind-numbing and some even rather stupid.

We then made a small web presentation [2] of the most interesting ideas and asked people to vote and give their suggestions. It has been a very rewarding experience.

[1]: http://dschool.stanford.edu/wp-content/uploads/2011/03/Bootc...

[2]: http://idea.diwank.name

Boy, [1] is a long document. I scanned through it quickly and noticed some good ideas, but I don't have the patience to do any of it in the way described. There's too much process.

Have you shipped any of the ideas in [2]?

> Boy, [1] is a long document. I scanned through it quickly and noticed some good ideas

I understand. It's a whole bunch of neat design processes. But it's huge! You can take a look here for the separate ideas. http://dschool.stanford.edu/use-our-methods/

> Have you shipped any of the ideas in [2]?

Yup. We're currently building IHeartCode (turned out to be the most popular). A rough prototype lives at http://iheartpy.com

Did your users tell you the animations or design wizardry are important to them? I find them really distracting, and couldn't find any useful content on iheartpy. I know it's rough, but you seem to have started with too much skeleton and no meat.

It's only a few weeks since we began working on it. And we've been working on the backend all this while. The design has received a wide spectrum of opinion: some seem to love it, others find it confusing. I think we'll redesign it once we get the backend finished.

We're filling in the meat right now! There's a lot of work to do and we hope to get things in shape so we can call it a beautiful pig and go from there.

Thanks for the feedback though. Would love to bug you some more if you don't mind. :)

There are only two things that you could do that would help me learn Python: create and curate good learning material. When it comes to education, I think the highest value even today is created by making good new content, not more tools.

> create good new learning material and curate good existing material

Great advice there and I totally agree with you. In fact, we are looking into incorporating great Python tutorials in the public domain to supplement our content.

Actually, we took the interactive approach because to people with little background in programming, the biggest deterrence is fear of breaking things on their PC. On iheartpy.com they can easily try out basic commands without that fear.

I like interactive, but it seems to work well only if you can simulate the commandline well enough in the browser (like Codecademy does). If you do anything advanced, it has to be done really well. These are couple of good examples:

http://worrydream.com/LadderOfAbstraction/

http://www.youtube.com/watch?v=7XUWpze_A_s

@revorad: Thanks for the links. I liked the Ladder of Abstraction.

On a different note, this discussion is slightly off-topic. Can I shoot you an email some time? (If you don't mind.) Also, I'm really sleepy now (yawn!)

Yeah of course, email's in profile.

I think this is one of the major points covered in the Lean startup. In essence, you start with your idea, and sometimes after you get customer feedback you learn that maybe one of your features should be your product. For example, @Flickr actually started that way. Flickr was at first a social gaming site, but when they implementing photosharing the demand for that feature was so overwhelming they made it their whole product. If you'd like to talk about your idea with me, feel free to email me, which is in my profile.

I usually start a project with a hard launch date. We decide what we want to build, and then decide which 80% we can strip out to meet this launch date. You may not have to start with a hard date, but if your runway is limited, it may help.

Either way, this will help you visualize the minimal viable product and you can go from there.

I agree with this. A hard launch date helps to give you focus, and decide what can realistically be achieved by that date.

It doesn't mean that your other features are discarded, it just means that you can get to where you need to be at the right time.

One other thing it does too is give you an opportunity to stand back after the deadline has passed and look at the project with fresh eyes.

For example, at the outset you aim at getting the ting up and running. Then once you are there, switch hats and become a user. Is the thing doing what you need? Are there bit's you don't actually like? Why don't you like them? Would one of your missing features solve the problem? Or, do you just drop that irritating feature?

I think this can only happen if you set the date, execute, and then step back.

Discuss the ideas with other smart guys. I've always found that when I think about an idea by myself, I can overcomplicate it and tend to underestimate how much work it will be. Sharing the ideas with other smart guys can counteract this.

Your question is super good. This may be the hardest part of coming up with a new business.

What do you do when the other smart guys want to make it even more complicated? - or worse, add even more features!!!

keep asking yourself "self, what is the minimum form of this idea that will provide value?"

Keep it dead simple and do not add any extra features until users start to ask for them. Let the user base guide future product development. Put up a feedback link on every page and be responsive, but do not build every requested feature. Just the ones that make sense. It's a challenge that takes discipline.

Talk to someone about it, who will act as a good lens/mirror for distilling it into its core use.

Reply on news.ycombinator.com