[chowes]

Not the OP, but what I have struggled with here is the feeling of being a "solution looking for a problem". It's a step before where you're at. It's not that I can't identify owners, it's that I can't identify _problems_.

I am lacking the domain experience to even have the first conversation, and it feels like paying people to ask "so tell me everything that is wrong with your business" is the wrong way to do it.

I know PG mentions "solve problems you have yourself", but I am not a business owner. I'm a software engineer.

That video you linked earlier - Designing the Ideal Bootstrapped Business - was incredible and feels like the right move once you have that idea. But what about finding that idea?

[enraged_camel]

A good way to think of it is that you aren't looking for problems. You're looking for smells.

Most business owners tend to be experts in their specific domain, where they have already used their knowledge and expertise to great advantage. But running a business entails more than just handling the problem domain itself. There's an entire category of tasks and responsibilities under the "business administration" umbrella that the business owner will not be an expert in, and will probably despise dealing with because it takes them away from the fun stuff that is their expertise. That's a good area to focus your gaze on.

For instance, the accounting clerk may be spending 4+ hours every day manually typing invoices into two different systems, but to the business owner this is probably perceived as a normal and expected course of business. The accounting clerk is unlikely to complain about it themselves either, since they are getting paid to do it (remember that Sinclair quote). But to you as a software engineer, double data entry is very obviously a red flag, and if you care enough about it you can do a deep dive and see if it can be eliminated using automation, and present it as a cost-saving solution.

Generally speaking, nobody is going to hand you a written list of their problems on a silver platter, and even if they do, the problems they have identified will be so general and vague (e.g. "we have a lot of inefficiencies in our accounting department") that you won't be able to simply go home and start hacking away at them. So you need to use a methodology to start peeling off the layers of the onion, so to speak. And that always entails follow-up meetings and learning other software systems and familiarizing yourself with various business practices.

At some point, you will come to the realization that you no longer view yourself as a "software engineer". Rather, you are a problem solver, and writing code is simply one of the many skills you possess. That's when you'll know you're on the right track.

[dhruvkar]

I hear you.

I was in Software for a couple of years and I only saw software/IT problems. But these problems usually had a variety of solutions and only some glue was required.

Now I've been in the natural stone industry for 4 years and I can't count the number of problems to which the solution is "add more people". So much data entry and data extraction from PDFs <-> ERP/CRM/Other software. 100s of man-hours spent on something that could be done with proper data formats and simple automation.

I personally believe that software engineers are SORELY lacking on all other industries besides software. We need more software engineers venturing out into other industries and identifying and solving problems.

[pnathan]

> We need more software engineers venturing out into other industries and identifying and solving problems.

this seems to line up with my experience well. But I don't have a good line of sight for me to actually experience those businesses outside of taking a non-SWE job and going from a well-compensated expert to barely-paid newb. Spending years learning a specific industry in the hopes that I can turn my former skills into a viable business seems like the wrong approach in several axes. I know VC groups (sometimes) have entire departments whose purpose is to understand other industries... it seems counterproductive for individuals to try to and go this route. Thoughts?

[dhruvkar]

Agreed, that's not a pragmatic path. But if starting a business is your goal, and finding a viable idea is your obstacle, I'd argue this is a sure-shot way of FINDING said idea.

Some potential paths can be:

1. SWE @ SW company -> "BA" @ non SW company or whatever term is used for generic-problem-solver in that industry.

2. Part-time hourly work in another industry. This is fairly easy through temp agencies.

3. Apprenticeship in another industry (perhaps in more hands-on industries).

Some are hard to get, others don't pay as well. But to find gold, I'd say some level of hardship is required, and this, in my view, is a bulletproof way of finding that gold.

Whether you're able to dig it out and then able to sell it at a profit, is totally another question.

[ProblemFactory]

> Part-time hourly work in another industry. This is fairly easy through temp agencies.

This sounds like a more brilliant idea than #2 in a list in a long thread.

Temp agencies are where businesses turn to when they have a reasonably simple problem and they are willing to pay to solve it.

[gbasin]

Totally agree. Software is just starting to scratch the surface of other industries.

Out of curiosity, what's your role in the space you're in now? Are you solving these data extraction problems?

[dhruvkar]

Hey Gary, I'm solving them using 3rd party tools (docparser and evolution.ai) at the moment to offload these types of tasks.

I don't have a fully working solution, just started testing with specific documents (steamship lines notifications) to see if it's a fit.

I think it'll be slow road for each department I want to tackle - logistics, accounting, purchasing, etc. Every department has this issue, and I'm sure products could be built to serve those niches.

[rorykoehler]

There was a post on here a couple of weeks ago that spoke about this. Essential reading for indiehackers imo http://reactionwheel.net/2015/10/the-deployment-age.html

[wastedhours]

Plot the day - talk to a business owner and get a sense of the hours they spend doing different tasks. If there's something they spend X+ hours per day doing - find what they want to achieve and optimise from there.

[jdance]

What solutions would you pay for as a software engineer? What would your boss/team lead pay for? You can't really do it for someone elses domain, you need a motivated partner in that domain for that (my general experience, of course there are exceptions)

[tropianhs]

> it's that I can't identify _problems_.

Why don't you start from your own problems? I bet you have some of them and you are not alone definitely.