It's occurring to me that the path I'm taking in building a product has a bunch of nuanced details in the process that I'd rather not forget. This is a description of the technical and supporting steps, (so that I have a reference later) but if you're doing something similar, you might find this process a useful way to go.

1. Finding a Problem

First, I determined what the problem was. I knew initially that it had to do with finding jobs. So then, I narrowed it down. What are the specific problems that are addressable? And by me? What I settled on was easy from the "why would someone want this?" perspective. Job hunting sucks in a billion different ways, so "making it better or easier" to address those general problems is not difficult to commit to.

However, when you're actually building something to help solve that general problem, (especially as a solo maker or small team), you're not going to solve the whole thing. You get to solve a couple of the sub-problems.

So I charted out the job hunting process and thought of many things that could help:

Interview Practice
Resume Writing and Review
Networking Advice and Intros
Job Skill Training
Job Discovery and Personalization

Evaluating the Sub Problems

The first three of this list is better served by others. I've personally tried 4, and for me, it's hard to stack enough lessons to make it worth it. As a solo teacher, it also means keeping hot new skills up to date with even more pressures than a dev. Specializing on something evergreen that people also really want to learn is a possibility, but nothing about that really stands out for me personally. I'm a generalist. Of course, there could be a team of teachers, a marketplace even, a platform... and so on. I don't want to do that. More time, more risk, and everyone teaching each other react isn't really the world I want to help make.

So I'm looking at job discovery. Ostensibly everyone in tech is hiring (this is kind of not true) and it's a seller's (job hunter's) market (this is also kind of not true). The reality is many people have a lot of trouble finding jobs in tech, salaries are suppressed (historically, structurally, and proportionally to the value they create), and while the money is amazing compared to other industries (unfortunately exacerbated by the effects of tech's influence) the jobs themselves more often than not contain a lot of pressure, short-term thinking, and propaganda you have to support.

So in the "why for me?" part of this, what I want to do is give tech workers more power. Currently, the only source of that power is the ability to leave and find a new job. Proactively interviewing is seen as disloyal, while restructuring an organization, changing focus (pivots, as well as increasingly serving B2B markets, or lobbying), are all fair game from the company side.

"You should quit" is advice I'd love to give everyone stuck in a shitty job, but it's impractical if you don't have other options. At the individual level, I'd like to empower this decision. At the industry level, I'd like there to be more consequences for being a shitty place to work.

I don't believe I can solve this completely, but I think I can help. As far as the scale of the problem, I've heard women talk about many instances of discrimination. I've heard genuine excitement about individuals or responsibilities or money or effects. I have never heard any woman say "[This Company] is a great place for women." The bar is so low that we've admitted an absence of grievances as the pinnacle of workplace harmony.

So in short, providing tools to make changing companies easier is in line with the world I want to help make.

At the individual level, it helps people get out of bad situations, and at the industry level, the worst it could do (when doing a job, let alone building my own thing, I often wonder what would be harmed if the company succeeded massively and didn't care about any mission beyond conquest) would be to enable a "mercenary" mindset among all tech workers. They would only do jobs for high pay. The companies would experience more turnover unless they kept people legitimately happy. That might require more spending on training, more honesty and dedication to mission, and less insistence on a growth curve that can only be harmful or illusory.

Ok, so in its most pokevolved form, this simple job hunting tool stalls VC funding as their growth curve and risk profile no longer line up. "Tech" the hockey stick is dead. "Tech" the making things with technology is still around. "Lifestyle Businesses" face less competition from VC subsidized ad buying and race-to-the-bottom service and product prices. Housing prices and tech salaries both fall momentarily as "startups" in their current boom or bust fall away.

Ok. I can live with all that.

2. Problem Identified: Job Discovery

So what's broken about job discovery? A few things.

There are a million job boards and a million jobs. None are all that great.
Platforms like linkedin snitch on you when you update your profile.
The Recruiter-Lite platforms like hired, et al, don't really give you a "warm intro" to companies.
Job info sites like glassdoor and salary are subject to PR blitzes from the companies (who are the ones who pay them.)

At best, these services offer you as a well prepared meal for companies to fight over. Either way, you're the inventory/product. One bright spot in all of this is Interview Cake, which makes the extremely shitty tech interview process less shitty.

But as far as finding a company you love, companies are doing the spend on the platforms that would be in a position to make that happen.

If I was running a job board, I'd be charging companies to promote themselves to the top of the list. And in the wildest success case, I'd make the most money promoting the most moneyed companies. All job boards are going to have this tension if they grow. Pushing the most moneyed companies and catering to searchers whose number 1 concern is money is what success looks like.

I'm not doing that. In my wildest success case, people looking for the most money are supported, as well as people looking for calm environments, dog friendly offices, legitimately mission-focused companies, and so on.

3. Planning Backwards

Love Letters

After deciding what to work on, I started planning backwards. Beginning with (fake) messages from people liking the service. This doesn't replace formal research methods, but it's cheap. These endorsements are guidelines for who you want to support, how, and overall the experiences you're looking to create.

Maximum Impossible Product (MIP)

Before building anything, making a list of features that you "could" make to solve the problem is useful. It's easier to cut down from a big list than to start with adding only the best ideas. So for me, that meant including everything I could do in this service, and borrowing from the pain points I wasn't specifically interested in. If I had unlimited time and money, and had to build a product that would help people find jobs, interview, prep their resume, etc. etc.

A pass at adopting the love letters here is a decent idea.

MVP

Ok, so now it's time to cut features. Everything that is not really possible gets cut. Anything that doesn't contribute significantly to the experience the love letters suggested. Of course, your love letters may need to be toned down as well. For me, if I had one that said "I got a job making 300K at a mission-focused worker owned tech collective," well, I'd probably need to scale that back anyways.

At this point, there should be 2 or 3 core workflows. So now the product is further constrained, not as something to support the love letters (which is broader), but to support a few workflows.

Workflows and Feasibility

At this point, you might get the urge to build the easy parts. Don't do that. All you need to do is make sure you can do the hard parts. Are there any particularly hard things for which there's no workaround that your workflows completely depend on? If so, you need to revisit the MVP. Cut a new feature list.

Pricing/Product-Market Fit

Another aspect of feasibility that the love letter/workflow doesn't necessarily support is a question of whether people would want it and pay for it. Does your feature list support the price? In my case, "yet another job board" would not be a good fit for consumers, so building a job board makes no sense. On the other hand, a few dollars per month to make job hunting less stressful? Yeah. That sounds good to me.

There's no guarantee anyone will want it, but personally I think a product built through a desire to help people with actual problems they have, with an experience that makes sense to them has a chance. Trust has to be established and they need to hear about it. They need to know it will help them.

As with the feature list, it's worth brainstorming the maximum pricing possibilities and working out different justifications. Play with billing cycle, cost per billing cycle, one-time, specials, partnerships, etc. Reasonable ones should be supported by workflows and love letters.

Naming Things

At this point, you should have an idea of what things could be named. So if you're committed to building the thing, it's worth exploring some basic typography, logos ("wordmarks" are the biggest bang for your buck), domain names, social media profiles, etc.

Marketing

There is a time to test things out with ads. There's a time to "figure out" marketing. Maybe read "Traction" by the Duck Duck Go founder. Decide a few channels to test.

4. The Actual Product

Now onto the thing I'm actually pretty good at: development.

Pencil and Paper

So you have that MVP feature list, right? Get that ASAP, and then start making wireframes. Pencil and paper. What do you want on the pages?

Tech Choices

People agonize over technology choices. There's plenty of risk in this process already, so go with what you know. If your design and UX can't build trust, then you might need to build or adopt new technologies (or pay for the expertise). Mostly though, you should be completely in your wheelhouse.

Boiler Plate

Regardless of what tech you picked, you're going to have to do some bullshit setup nonsense. Just get it out of the way.

Views (or "templates", depending on your stack)

Next up, you want an index.html page. Just one. It should have a core part of the core experience on it. When you stop being able to fit the experience into that page, make another one.

At this phase, hardcode everything that would be data in a database. Copy and paste html.

Repetition

Once things start to take shape on the UI, you'll probably have a lot of repetition. You might get the urge to put things in the database at this point. Wait on that. Use loops (or whatever list data presenters you have) and put the data one layer deeper in the stack (in Rails, this would be "controllers").

As some combination of arrays and hashes, they will be more flexible than the overhead with adding something new to the database. That means that if you decide to change the names of something, it's a simple search/replace in your editor. More importantly, you're not far enough along at this point to fully commit to the UI. If it changes, your data likely will too. Also, in dealing with just a few records, you can manipulate them more easily like this (copy/paste again) rather than using an ORM. Finally, you might decide that some of this information (especially static, and relatively small data sets) might live better as code, whether that's arrays and hashes or a CSV. And if you happen to never need a database at all? Well, you've just simplified your app significantly.

Time to Stop Pretending

At some point, you'll find yourself starting to take extra actions in a workflow that don't need to happen. Maybe it's a toggle between dev and prod. Maybe it's adding and removing code manually. Maybe it's realizing that you need to see 1000 records before the UI would make sense. So then you tool up. Get your data in a database.

Key here is that your data was structured based on your workflows demanding it be there, not because you thought of how to diagram it. There is something admittedly satisfying about drawing a database schema up, building scaffolding from it, and then building the views, but it is very backwards. The old Rails idea of having 7 "RESTful" should rest in peace. How many times do you want to edit more than one model at a time? Pretty much always. How often do you want to display a summary view of things, and absolutely need an atomic view as well? It's not 100%. If you do the [create, new, index, show, delete, edit, update] defaults with rails controllers, it's going to need some attention later, or be a very fragmented experience.

Single User Mode

Don't build auth. Don't do it. If you need to put something behind basic auth, fine, but don't build out the whole login thing. Until you lock down the workflows, you want to be flexible and also be on the lookout for potentially sharing data between people.

Plus, there are decisions to be made with this. Should you do two factor? API keys? Username/PW? Oauth? From which services? Is there a delegated admin? All of that. You can spend a lot of time on that and not touch the core workflows.

Cowboy Mode

Don't write tests... at first. When you're still locking down the core functionality, they're just dead weight. HOLY SHIT though, use version control.

Once things solidify a bit, then your confidence frame of reference shifts. Initially, you're probing for being right about the features. Once you start worrying about the code being right, (and variations on good), then tests will increase flexibility.

After the Workflows (A new plan)

Really, by this point, it gets into the detail work. Once you've been in cowboy/single user mode for a while, it makes sense to actually create a todo list. Before this point, it would have been difficult. We didn't have the "form" of the experience down yet. Now, we can see what's missing. These pieces will be much smaller than the "workflow level" that we specified before. One fairly common thing is to put some ideas of "nice to haves." This can let you document what you think is cool without the obligation. Maybe you'll even do it, but that simple binary of essential/non-essential will save you from a list that's too long.

Eventually, the auth, the tests, the polish. It all comes.

One last thing. It's worth mentioning at this point that any management of tasks beyond a simple list is probably overkill if you're working on your own.