Hacker News new | past | comments | ask | show | jobs | submit login

The key to these types of solutions is always to follow the 80/20 rule. For example, it’s foolish to say and attempt “I will automate all of your data entry people” because there will always be weird idiosyncrasies that are better fit for humans. You will dash yourself against the rocks trying to get a “100% complete” solution.

Instead, create software that allows 1 person to do the job of 5. You create massive business value without getting sucked down the hole of edge cases.




True. In the same spirit, I'd also add record linkage to automated data entry. It's a big problem both if your previous data is noisy or your automated solution doesn't transcribe some fields correctly.

A simple probabilistic programming solution can work really well.


I’m building a tool to speed up data entry. It highlights OCR‘d words with low confidence for human review. It uses templates for capturing structured data and a fast interface for capturing unstructured data.

It grew out of consulting projects and is almost ready for beta testing if anyone is interested in playing with it and giving me some feedback - my email is in my profile :)


Email sent.


How do you guys network with the right business people to speak their language and find out how their processes work? You need that info (a problem description) before you come out with a solution, don’t you?


Just ask. People absolutely love talking about their problems, it'll probably be the most animated thing they have to say about the business they're in.

"Some people profess difficulty at finding applications to write. I have never understood this: talk to people. People have problems — lots of problems, more than you could enumerate in a hundred lifetimes. Talk to a carpenter, ask him what about carpentry sucks. Talk to the receptionist at your dentist’s office — ask her what about her job sucks. Talk to a teacher — ask her what she spends time that she thinks adds the least value to her day."

https://www.kalzumeus.com/2010/03/20/running-a-software-busi...


The "just ask" approach is very tricky. It does not emphasize a critical element : Most people love to rant and complain about things that annoy or bother them. People rarely if ever get to ideas to solve problems or even to describing the underlying problem.


> People rarely if ever get to ideas to solve problems or even to describing the underlying problem.

That's your job. Develop hypotheses about what the underlying problem is and ask them questions to try to falsify them. Develop hypotheses about solutions and build mockups or proofs-of-concept and have them try them out to falsify them.

No one will hand you a business idea on a platter. But problems to solve are the easiest thing to find in the world.


You're right its my job to find solution to problems.

I meant to say 'Just Ask' and 'Problems to solve are easiest to find in the world' are very misleading things for a beginner.

Just asking won't lead you to a solution and identifying solvable problems are incredibly hard.


The question I was answering was: "How do you guys network with the right business people to speak their language and find out how their processes work?"

I don't think "just ask" is misleading at all. The fact that most people will happily complain about their business processes but won't have ideas to solve them doesn't make it "tricky", it makes it an opportunity.

There might be fields of endeavor where identifying solvable problems is incredibly hard, maybe in academia or politics, but business processes? Execution and, if you want to get rich, scaling up are hard. But identifying solvable problems with people's business processes is totally one of the "easiest [things] in the world".

See also: http://www.paulgraham.com/schlep.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: