DaedTech

Stories about Software

By

To Find a Niche, Learn Why Your Company Pays Your Salary

My belief in picking a niche for yourself becomes obvious to anyone who reads more than a post or two here.  I’ve written too many posts about it to list, and I talk about it on my Youtube channel these days.

But today, I’d like to reference a couple of specific posts where I talk about this in order to flesh out a concept.  Here are those posts.

  1. Just under 2 years ago, I wrote a post about how you could pick a specialty with the help of your resume.  My advice was to look at the “key accomplishments” sections and start brainstorming with those.
  2. Earlier this year, I wrote a post about picking a niche.  And, in that post, I distinguished between generalizing, specializing, and niching.  Specializing involves looking at your own skill set, picking something you like, and hoping people want to pay for it.  Niching involves looking at needs that others have and filling those needs.

Here’s the gist of what I want to talk about today.  2 years ago, I gave advice that would indeed help you pick a specialty.

But, I actually think that it’s, at best, locally maximizing advice to help you pick a niche.  So I’d like to course correct a bit with my advice to the countless people that ask me for help finding a niche.

Backstory: The Employee Mindset Problem

To set the table on picking a niche, I’d like to briefly reiterate something I’ve talked about in detail before.  Learning to be an excellent employee is like a vocational program for how to suck at being a business owner.

Succeeding as an employee means developing a generalized skill set that a company can deploy in myriad ways over the course of years.  It also means developing a track record of “exceeds expectations” — doing all that your manager asks of you plus walking the extra mile.  These are traits that will lead to highly successful and probably rewarding careers.

But they won’t help you in the slightest when it comes to going off on your own and picking a niche.

In fact, they’ll actively work against your interests.

A career of making yourself broadly useful and pleasing a boss, who handles the strategic while delegating the tactical to you, leads to a freelance situation in which you unwittingly seek bosses in the guise of clients and depend on their approval and desire to toss you miscellaneous tasks.

This, obviously, makes for a poor business model.  But the employee mindset has an even deeper issue besides: employees spend entire careers having only a vague idea of why anything they do is worth money to anyone.

If you’re employed, do you know this?  I mean, really?

Can you tell me what impact it would have on your company’s revenue or cost if your job just went *poof*?  Can you tell me how your activities yesterday made or saved the business money?

The Problem with My 2017 Post and with Specializing

Alright, with the groundwork lain, let’s dive back into my advice about specializing.

In that post, I talked about using the “key accomplishments” section of one’s resume to pick a specialty.  I used a really old resume of mine as an example:

Ah, Team Foundation Server.  I’m so old.  But let me put down my cane for a moment and add some context around these key accomplishments.

Many of My Key Accomplishments Happened During Pockets of Downtime

In some ways, this was the best job I ever had.  The company made a product that helped people profoundly.  They were generous with perks, patient with employees, providers of a beautiful office space, and ahead of their time with things like flex hours and casual dress.

But, in other ways, it was professionally rough.

For one thing, the process was super waterfall.  Like, “here are all your features, devs, let’s meet back here in 6 months” waterfall.  I would, typically, at the risk of sounding like a braggart, take one of the larger or more critical features and finish with months to spare.  Not surprisingly, this produced boredom and lots of free time.

Finding that I could only run up my Stack Overflow score so high, I found other ways to occupy my time.  Some of those ways were “exceeds expectations” employee work in the form of most of my key accomplishments.

But others were more a question of ascendant opportunist amusement.  It was, for instance, at this location that I had the spare time to try out my armchair anthropologist skills and first chronicle the migratory patterns of real, live expert beginners in the wild, actually saying things like “I totally write unit tests, but I just don’t check them in.”

Location: In the office on Saturday, reverting all your changes from last week
Turn-Ons: Sunset walks away from builds I’ve broken
Fun Fact About Me: I can say “well, actually” in 43 languages.

How “Key” Were These Key Accomplishments, Really?

I spent my time there in a pitched battle to win hearts and minds, slay 10K line singletons, adopt unit tests, and generally try to bring a modicum of sanity to the codebase.  And my key accomplishments were victorious battlefields in that war.  In spite of management’s weary skepticism and entrenched people with formidable seniority and even more formidable silliness, I won ground, inch by inch.

But, wading upstream in a river of jello is tiring.  So, I put these key accomplishments on my resume, hoping to put out a signal to the kind of companies I’d rather work for, and I left.

And, do you know what happened to my key accomplishments after I left?

Commented out unit tests, removal of automated testing from the build, and abandonment of code metrics, among other things.  No one in the organization cared enough to keep these things in place.  (As a satisfying and symmetrical aside, that company did, years later, call me back to consult for a time on how to fix things.)

So, were these really “key” accomplishments from a company and business perspective?  Nope.

Would anyone in management have explicitly paid for these things (apart from rescuing a feature and leading another one)?  Almost certainly not.

Should I, therefore, select these things as the basis for a prospective niche?  Definitely not.

What You’re Most Proud of Isn’t the Same as What Others Will Pay For

This is where the employee mindset comes into play.  These were things that I was proud of and that, I could just feel in my bones, were the RIGHT thing for the company to do because reasons.  But I had no idea who, if anyone, would pay for them or why.

And that’s the fundamental problem with specializing versus niching and why it’s so tempting for people from the employed world.  It involves looking at yourself, what you’re good at, and what you like doing, then deciding that will be your business.

Then, you just leave the rest to fate, I guess.

Would companies have paid me to add automated test suites to their builds?  To switch them over to new source control platforms?  To administer lunch and learns and knowledge bases?

Maybe.  Who knows?

But the problem is that I had absolutely no evidence to suggest they would.  I did those things, and management and staff responded with, “hey, that’s pretty cool, I guess, good job.”  That’s a far cry from “shut up and take my money.”

Let’s Revisit This Scenario, but Pick a Niche, Instead of a Specialty

The true, core problem with using your key accomplishments (or, worse, your tasks, like “implement WPF functionality”) as niche ideas is that niches are all about others, and those things are all about you.

Your only evidence that they might have value is that an employer once paid you to do them.  But your employer really just pays you a salary in exchange for doing whatever they feel like having you do, and neither you nor anyone above you in the management chain probably has any idea of the market worth of your activities.

So, let’s reboot looking at my resume here.  But this time, let’s reason not about what I did or felt proud of, but rather about why the company might have paid to employ me.

My Case Study: The Business Context

(Please note that, since this is many years in the past, and I’m just offering this as a thought exercise, I might not have all of the market particulars exactly right.  It won’t matter.)

This particular company manufactured hearing aids and distributed/sold them globally.  My particular group did not have responsibility for the firmware in those devices, but rather for something call the “fitting software.”

Fitting software is what hearing doctors (called audiologists) use to configure the hearing aids for their patients.  My group, at the time, was working on creating a visually appealing, modern-feeling WPF application for those audiologists to use.

So, why pay me?  Or, why pay anyone in my group in general?  Why pay people to build fitting software?

This is actually more complex than it sounds, because nobody paid for the fitting software itself.  The company gave it to the audiologists for free, because it greased the skids for sales of the actual revenue generator: hearing aids.

Why Was My Employer Paying Me?

With that in mind, and discounting fatuous answers, like, “management is stupid!” let’s examine why it would be worth it for the company to pay lots of money to write software it gives away for free.  Why were they paying me?

  • Audiologists are brokers of sorts, so there’s value in anything that makes them favor re-selling your product over others.
  • There are a lot of regulatory requirements for hearing aid settings, and the fitting software helps with that, acting as insurance/CYA for audiologists, while also ensuring that their patients aren’t victims of bad settings.
  • In conjunction with device firmware, fitting software can enable killer features that appeal to consumers.
  • Fitting software makes customization and adjustment of settings easier, leading to better/longer brand satisfaction.

There are probably other reasons besides, but this is enough fodder for the purpose of the post.  At the broadest level, everything here results to hearing aid sales enablement.  I worked on software that made brokers more likely to recommend our product and that made users more likely to enjoy it and pay a premium for it.

Turning Motives into Niches

Now we’re getting at some actual niche ideas.  Unlike “unit tests in the build” or “C# and WPF” we’re now trading in actual market considerations.

These are the reasons that money appeared in my checking account every other week, which means that these are proven reasons that somebody might pay me as a free agent or business owner.

To continue the thought exercise, here are some very off-the-cuff niche ideas.

  • One could have a niche convincing audiologists of the merits of a particular hearing aid and/or its fitting software.
  • Alternatively, one could become an expert in ways to bolt killer features on to existing hearing aids (with fitting software or otherwise).
  • Making it easier (again, with fitting software or otherwise) to customize hearing aids settings would have value to the manufacturer.
  • Audiologists would likely pay to have rigorous safeguards against misconfigurations (or hearing aid manufacturers would pay to have assistance here).

I don’t know if these are great niche ideas, or even viable ones.  But I do know that money already changes hands here, so you’d be looking at questions like “is there too much competition” or “could I feasibly deliver this for a reasonable price.”  This stands in stark contrast to the questions many of you flailing at niches are asking (or should be): “does anyone even care about this” or “is this just miscellaneous labor?”

Niches Stop the Degrading Generalist Madness

One other thing to note here.  There’s no mention of the chipset on the hearing aids or the data storage medium for settings with these proposed niches.  There isn’t a technology or a stack or even a programming language anywhere in site.

Why not?

Because it doesn’t matter and nobody with money cares about that stuff.  As the niche-filler, that’s your problem.

And your customers are content to let you handle it, rather than administering trivia quizzes about object oriented programming to see if you’ve earned enough experience points to do the job.  (I mention this because a lot of folks writing to me about trying to do freelance software development lament the neutron-star-like gravity well of the tech interview for generalists)

Your Niche-Picking Homework

Let’s wrap by talking about you.  How do you apply this to your own situation?

Well, just look back at your job history, or your gig history if you’re a freelancer.  For each one of those, start doing thought exercises about why people paid you, and don’t stop until you hit an end consumer or a profit/revenue motive.

In other words, “I got paid to make fitting software” doesn’t work without understanding why the fitting software makes or saves the company money.  (Also, for those of you working for app dev “consulting” firms, the fact that you’re “billable” doesn’t really count, since it just kicks the problem down the road a few feet.)

But what if you’re not used to thinking this way?  Well, just ask people.  Seriously.  They’ll probably enjoy or appreciate it.

If you do this at your current job, it has only upside.  “Hey, boss, philosophical question for you — can you help clarify where I fit into the business, strategically, in terms of helping it make or save money?”  A lot of leaders will probably find a techie asking this question to be a massive breath of fresh air.  But, even if they don’t care or can’t help, they can probably tell you who you should ask.

I talk a lot about how picking niches is about other people, and you should start asking them about their pains, wishes, dreams, etc.  And that’s true.

But if you want a serious head start, you can think about your past work and why it resulted in pay for you.  If you want to find a niche, follow the money.

7
Add a Comment

avatar
2 Comment threads
5 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
3 Comment authors
MikeErik DietrichTwoQuestions Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
TwoQuestions
Guest
TwoQuestions

How do you know if your niche is too broad or too focused? For most of my career, I was tasked with turning convoluted Excel documents into actually documented business practices, where half that documentation is in the form of a report suite. It’s a challenge sorting through social status jockeying BS, but that seems a little broad. “Translating Excel sheets to web applications” sounds a bit tech-specialized too, and it feels like I’m thinking like a cog instead of an opportunist. Does “I can make your data actually useful and actionable” sound like something a small restaurant chain (for… Read more »

Erik Dietrich
Guest
Erik Dietrich

I’ve logged this as a question to answer in the future, but I’ll say for now that I think it’s mainly heuristically: 1. Too narrow if nobody seems to have a need. 2. Too broad if it doesn’t trigger what Jonathan Stark calls “a rolodex moment,” where explaining what you do to a third party causes that person to say, “oh, I know exactly who you should talk to.” Turning Excel sheets into a specific kind of documentation sounds intriguing and like it could be in the sweet spot, potentially. Definitely a rolodex moment — if I run across anyone… Read more »

TwoQuestions
Guest
TwoQuestions

Thanks! I’ll keep that phrase, “Rolodex moment” in mind.

Mike
Guest
Mike

So what would be your niche and what to pursue in your example with the hearing aid? Was the value you gave by making the complex and hard techwork that this software is working -> delivering the software in a regulated environment. OR That instead of the tech work you should go to audiologist convincing then to buy your software and find new features? I am asking as I am working in a similar field where I managed project for regulated software and was doing all the tech and grunt documentation work as this was a need for the company.… Read more »

Erik Dietrich
Guest
Erik Dietrich

Hi Mike, I’m actually not really saying either or making a recommendation one way or the other. Basically, this post was the process of me using that job to general several different niche ideas. So, if I were actually looking for potential a niche, I’d probably do the same exercise for several more gigs/jobs, forming a large-ish pile of potential things to do. Then, I’d narrow the field based on what seemed most probable, what I’d enjoy, what seemed like the best opportunity, etc. With some finalists, I’d then set about doing market research — scheduling calls with people to… Read more »

Mike
Guest
Mike

Thanks for the explanation. Ok now I get it, it was about various examples for finding niches. True, I always wanted to pin one down but did not enough market research.
And what do you think about anticipating niches? I have the impression that for example hearing aid software is getting highly connected and more regulated and building a career to help these companies interact with all these systems could be a niche in a few years from now?! Or you would stick with whats the market today?

Thanks

Erik Dietrich
Guest
Erik Dietrich

I think that recognizing/finding niches is a skill like any other, and not an easy one to become proficient in, either. So my recommendation would be to start recognizing ones that currently exist before trying to anticipate them.

Even the most basic way of recognizing demand of some kind about a topic — researching google search term volumes — shows people how surprisingly off they are about who searches for what.