Skip to content

What I wish I had known when I was starting out as a developer

As I get older, I wish I could reach back and give myself advice. Some of it is life advice (take that leap, kiss that girl, take that trip) but a lot of it is career advice.

There’s so much about being a software developer that you learn along the way. This includes technical knowledge like how to tune a database query and how to use a text editor. It also includes non technical knowledge, what some people term “soft skills”. I tend to think they are actually pretty hard, to be honest. Things like:

  • How to help your manager help you
  • Why writing code isn’t always the best solution
  • Mistakes and how to handle them
  • How to view other parts of the business

These skills took me a long time to learn (and I am still learning them to this day) but have had a material impact on my happiness as a developer.

I am so passionate about this topic that I’ve written over 150 blog posts. Where are these? They’re over at another site I’ve been updating for a few years.

And then I went and wrote a book. I learned a bunch of lessons during that process, including the fact that it’s an intense effort. I wrote it with three audiences in mind:

  • The new developer, with less than five years of experience. This book will help them level up.
  • The person considering software development. This book will give them a glimpse of what being a software developer is like.
  • The mentor. This book will serve as a discussion guide for many interesting aspects of development with a mentee.

The book arrives in August. I hope you’ll check it out.

Full details, including ordering information, over at the Letters To A New Developer website.

Lifehack Mistakes Programming | moore |

When is software done?

This is something I’ve been thinking about recently.

First, let me clarify that when I say software being done, I mean a particular feature. I don’t mean an entire package of software. A standalone application or SaaS software package is never actually done; there’s always new desires and demands from human beings, and all pieces of software must expand until they either send email or build their own messaging inbox because they can’t be bothered to interface with email. The most successful communications protocol in history; but I’m not bitter.

I’d argue that a holistic view of software success actually looks at the user and asks when a certain percentage of them — say, 7% or 15% — are using it. What that exact percentage should be is a matter of art and depends on the feature being built. Not everyone is going to use every feature of every piece of software. You won’t always use every feature of software you write for yourself.

But people are using this feature, and critically, they were able to discover it, and they’re happy that they discovered it, or at least not actively angry about it. Discovery, usage, and happiness. (Look ma, it’s a framework!). If you don’t have all three, you’re in trouble.

What people mean when they say software is “done” depends on where they are in this picture. If you’re a developer focused on a certain set of features, deep in a codebase, whether you’re writing code manually or using some kind of tooling or agents to write code, you might consider the software done when it’s merged to main, or more likely when it’s deployed. That is, when people can interact with it and learn the code the same way jessitron talks about in this beautiful piece. That’s deployment, but it’s only the first step. If you’re a marketing person, you might consider the software or feature done when you’ve launched it: submitted the press release, sent a bunch of emails about it or otherwise tried to engage people and teach them about it. If you’re a business person, you might look for the first deal that was signed because of this software feature, or maybe the first incremental bit of revenue you can point to. If you’re an end user, you might consider a feature done when you use it for the first time. Each of these is really pointing at one leg of the same framework without necessarily covering all three.

So let’s take the “discovery, usage, happiness” framework leg by leg.

Discovery. The cost of creating software has decreased drastically (ahem, AI, ahem). And when the cost of one component of something decreases, what happens to the other pieces? I think you can’t lose track of the ultimate source of value, which is: a user discovers this particular feature, whatever it is, uses it, and is happy about it. Discovery means you have to have users, which is why the go-to-market or distribution side of software is so important. After all if someone doesn’t have your entire software package, they won’t be able to find the cool new feature you just shipped.

Discovery also means your users need to be able to find the new feature of their software. Lots of options for helping them:

  • in-app notifications
  • email
  • a pop-up on a related feature
  • targeted communications because you’ve seen a user explore related features
  • hopping on the phone with them (if you’re a smaller company)
  • a face-to-face conversation and show people what’s new
  • release notes

There are a lot of different ways to do it, and the truth is that you aren’t going to be able to do just one of these. Inform folks the way they want to be told; everybody wants to be communicated with in a different manner.

Usage. After discovery comes usage, which means someone actually trying the feature out, at least a few times. At a base level, it needs to work the way they expect it to. No surprises. If it doesn’t, people won’t get past this stage no matter how well you nailed discovery.

But usage isn’t just about whether it works; it’s about whether it’s worth the effort. The friction of using the feature should be calibrated to the perceived value someone will get from using it. Not the value, the perceived value. And not value for you, the software provider, but for the end user.

For example, if you are adding a feature to enable better recommendations, don’t have a 100 question survey. Ask one or two questions.

Happiness. Happiness is a step beyond usage. It’s someone incorporating the feature into their normal workflow. People don’t use software just to use software; they’re using it to accomplish something in their lives, whether that’s communicating with friends, doing part of their job, or just amusing themselves.

Once something becomes part of how they actually get things done, that’s happiness. And that means it needs to not be a constant churn of change.

If you push too much churn on them (constantly pushing out features, changing interfaces, tweaking things, and not letting people turn new features off) you’re going to make them dissatisfied, and they’ll never fully incorporate it into how they work.

Maybe “happy” is too strong a word. Or maybe you just want people to be content, or at least not upset — it depends on the kind of software you’re using.

And it’s worth saying that people hate change. I hate change myself, so some percentage of your users are always going to be grumpy about it. Don’t want to measure happiness just at the moment they encounter the new feature; that’s usage. Some people, early adopters, will be thrilled to be exploring new areas, while others will be pretty pissed off. So you want to gather that data after a certain period of time has passed.

Have I ever worked somewhere that has this kind of maturity around it? No.

Would I like to? Yeah. I think that if you can close the loop on discovery, usage, and happiness, you can build software that people love, and that becomes a sustainable business.

It doesn’t matter how much your competitors churn out software because it’s cheaper to do; you’ll win if you make software that can be discovered, that people use, and that they like.

Programming SaaS Technology | moore |

What I Learned From Playing “Spelling Bee”

I’ve been playing Spelling Bee for a few weeks now, where you guess words from a selection of seven letters, one of which must be used in every word. The letters are arranged in a hexagon with that primary letter in the middle. If you want to learn more about how to play it, follow the directions here:

For information on how to play, select the More in the top right corner of the game and then select How to Play.

It has surprised me. I have learned that “oleo” is a word and that you can tell how hard the puzzle will be by looking at the rankings.

But what I really wanted to talk about is the lessons I’ve learned from playing and how they can apply to your career.

Switch Things Up

There is a button that can flip around the arrangement of the letters around the hexagon. The primary letter remains in the center, but all the others are moved around randomly. When I first saw that, I thought it was silly. But I found it to be super useful over time. When I’m looking for words, I get stuck. Pressing the rotate button reveals new words because it changes my perspective. Just moving the letters around makes new words visible to me.

In real life, when you feel stuck, you can sometimes make progress by flipping things around. I’ve done this in my career.

I quit my first head of engineering job where I was trusted by the CEO, had loads of autonomy and worked on software that helped people find homes they loved. After, I enjoyed the freedom of lucrative contracting and learned a ton about other tech stacks.

I took a quarter life sabbatical when I was around 25. After months of leisure, I learned that, yes, I really did like reading about parsing XML.

I left the food-focused startup I’d co-founded (an area I’d dreamed of working in) which had just raised a seed round. Departing led me to an entirely different area of the software industry that I love and never would have explored at the startup.

There are of course other ways to gain new perspective than quitting jobs: changing routines, asking friends for advice, or even taking a new route to work. Before you give up on something, flip the script and see what the results are.

Just Try Something

Sometimes you just have to try things. I will often put in words that I know are not valid, just mashing different combinations of vowels and consonants, like “manu”. This is not an English word, nor will it ever be. Spelling Bee also disallows proper nouns and three-letter words, but I’ve definitely put in plenty of those. Even though these are all invalid moves, they are movement. This helps me not feel like an idiot just staring at a phone screen. Even better, it can trigger other ideas. It’s a lot easier for me to visualize a full English word when I see part of it, rather than staring at those seven letters in a hexagon. After typing “manu” I found “manual”.

There is value in just taking a step forward if you aren’t sure what to do. If you have some kind of goal in mind but aren’t sure how to get there, do something. Take a step towards that goal.

If you are trying to get a job in the software industry, especially right now, it can feel overwhelming: so hard, so difficult. But you can take concrete steps towards that goal that are smaller. These steps, when you’re looking at them, may not make 100% sense and won’t make you money. But they are helping you on the path towards employment, and will lead to other steps to take that will get you closer to the goal.

I’ve written before about how attending meetups is a fantastic career move. Doing so doesn’t have an immediate payoff, which is super frustrating when you’re trying to find a job, when your bills are piling up and your savings are draining. It’s super hard to think “I’m going to take an hour out of my day and go hang out with geeks talking about ruby“. But joining a meetup can open up other doors.

Just like typing “manu” reveals “manual,” going to a meetup repeatedly can help you get a reputation in a community, offer contract opportunities, let you understand the market, and may help you get a job. This is just one example. There are a thousand different steps you can take towards your goal. It can be hard to determine which step is the right step, but the lucky thing is that there are many right steps. You just have to start.

Double Down On What Works

I like to double down when I have a pattern that is working. In Spelling Bee, if you see a pattern of “ull” being a portion of a word, you should double down on that while you’re thinking about it, and make all of the “ull” words you can. Same with suffixes like “ed” or “ing”. When I see that, I know that I can spell both the initial word like “mint” and get more points by adding “ing” to get “minting”.

Even though I have 100% been guilty of a grass-is-greener outlook in my life, where I think, “oh, I’m frustrated with this company, or in this position, or with this situation, it’ll be better over <somewhere else>”. But after 25 years in software development, I know that every place has its issues. I was recently talking to a former colleague, and he was just hired at a super impressive top-tier company. He was talking about some of the issues they have and some of the burning fires. I would not have suspected it from the outside, because they look like they’re killing it.

Sometimes, you should look for the good things in your current position and double down on them. This isn’t the same as staying stuck; it’s the opposite of that. Instead, this is about noticing when something is actually working and resisting the urge to abandon it just because it’s familiar. Switching helps when nothing is working; doubling down helps when something is.

What does it look like? It might be working a bit extra, taking some free time to study for an employer-funded professional certificate, making small improvements to your team’s workflow, or just bringing your best self to work every day. All of these are taking what works and doing more of it. Double down on what is currently working for you, and it’ll make you happier and you’ll score more points.

Three lessons I learned from the Spelling Bee game: switch things up, just try something, and double down on what works.

Who knew that looking for words could be so educational?

Jobs Lifehack Startup | moore |

What It’s Like To Lead An Engineering Org: Thoughts On “CTO In The Loop”

I just read CTO In The Loop by Balki Kodarapu. It’s free on Kindle through July 20th, so if you want to give it a read, go do that now.

It’s a narrative arc following a developer, “Sam”, who starts as a software engineer at a startup, and ends up a fractional CTO after a career that includes engineering manager, director of engineering and VP of engineering at a company that IPOs. The book was a fun read, and does a good job describing what it’s like to build a company and a software business from the early days to a more mature organization.

The realities of Sam’s growth ring true: he starts out focused on features and clarity, and then moves up levels of abstraction. He loses touch with tasks and areas that used to matter, but gains higher level views and more ability to influence the organization. As a director, if you’re still reviewing PRs the way you used to, you’re basically breaking your organization

We also see the evolution of several other characters, including Priya the project manager, Mei the UX designer and Jack the senior developer. Some of these folks stay with Sam across companies, while others pop in and out, just like real world colleagues.

Some details felt a little forced; for example, locking down a GitHub repo and preventing merges to the main branch are treated as a major effort, when most software shops do that pretty early.

I especially liked the portrayal of the thorny moments of management that Sam encounters:

  • firing a team member
  • multiple rounds of layoffs (and subsequent hiring)
  • changing his understanding of the constraints and goals of the engineering org he is in

I also really enjoyed the emphasis on integrity, and how the protagonist was repeatedly challenged to hold onto it through different stages of business growth. I think integrity is an easy thing to write about and much harder to actually live. In the moment, you tell yourself that just this one tweak that you might feel uneasy about will move the business in a positive direction. But doing this repeatedly only works in the short term.

The benefit is immediate and the cost is deferred, and avoiding these kinds of decisions is a constant challenge as an organization grows.

The hard part is that it’s rarely obvious where the line is. Most people agree you shouldn’t commit fraud. But there are dark UX patterns that benefit the business. For example, you could make it much harder to unsubscribe from a service than it was to subscribe; every organizational incentive points that direction.

Another example is the integrity in making it easy for a customer to leave: making it easy for people to export their data and take it with them. That’s a frustrating tradeoff for whoever’s job it is to sell the product, but it’s a pretty clear-cut example of integrity. You want to earn people’s business, not hold their data hostage.

There are other places integrity shows up over the course of a career, but the author does a good job of showing how it is hard to maintain, especially when you are focused on the day to day of building a software business.

CTO In the Loop is a fun, easy read. I read it on the Kindle app in about 2 days while on a vacation. I’d highly recommend it to people early or mid-career in software who are curious what life looks like at a different level of the org chart. When I was younger, I assumed people at higher levels had a lot more control, agency, and power. That’s true, but they are also further from the customer, removed from knowledge of how technical systems actually work, and have a lot less clarity about the day to day. To say nothing of many competing demands that folks at the director or higher level have on them.

Writing code, or telling an AI how to write code, is one thing. Thinking about what the company looks like in one year or five, how to bring different teams together, how to manage investors and understand the market, and how to keep every department rowing in the same direction: that’s a tremendously difficult job. This book is an accessible narrative of those tensions, to which I don’t think new or even mid-career developers usually get exposure.

So go check it out. Did I mention it’s free on Kindle through July 20th?

Balki, thanks for writing this excellent, interesting fable of a software developer’s career.

Books Lifehack Startup Tips | moore |

What I Don’t See When I’m Envious

I’m getting to the age where peers have accomplished a lot. I’m not talking about people who were exceptional out of the gate and did great things in their 20s and 30s. I’m talking about people that felt like genuine peers, but now have done things like:

  • made a boatload of money
  • built a business such that they have all kinds of freedom
  • are well known in their fields

These folks have things that I want. And I feel like I’m just as talented. I could be where they are and have what they have.

In my mind I often think “why does <X> have that and I don’t”. This envy is not constructive, but that doesn’t stop it from popping up from time to time. I think I’m getting old enough that status and legacy are starting to matter in a way they didn’t a decade ago.

Here are strategies I use to combat envy:

  • Remind myself that I don’t actually know everything they have. I can see certain aspects of their life, but even for close friends I don’t know everything, just what they choose to share. The friend who is a professor who works with interesting projects and gets the summers off might have to deal with horrible politics or a low salary. I just don’t know. That means I don’t know enough to know if I’d actually want to trade places. I am idealizing what they have and not understanding the downsides.
  • Even if I would want to trade places, I don’t know what they went through. When I see a friend with the thriving business who has flexibility and can work when he wants, I don’t see everything. I don’t see how he had to be tethered to it for years, or the risks he had to take, or the multiple years of 60+ hour workweeks and the stress that wrought on his body, family and friends. I try to imagine the late nights and the worries in the same way I imagine the benefits.
  • Remind myself that I have agency and can work toward what they have. Even though I’m mid-career, if I wanted to adjust things to move towards what someone I see has, I can do so. As mentioned above, I need to be willing to make sacrifices, but I am lucky enough to have the space to consider it. With sufficient focus and effort, I can do most anything, I just can’t do everything.
  • Even if I want to trade places with a friend, know what would make me happy, and would have been willing to make the sacrifices to be where they are, I am still discounting my current situation. It’s very easy to think “oh, <Y> would make me happy” but if I can’t look at where I am and be grateful, I might be kidding myself. And when I do take a hard look at where I am, I do feel more gratitude and satisfaction. One of my hacks when I’m feeling down is to just list 2-3 things that I like about my life.
  • Related to feeling grateful for what I have, I also try to remember that just as I am looking at people and saying “why can’t I have what they have”, other folks might be looking at me and saying the same. In fact, I might have said the same 20 years ago if I was looking at someone where I am now. It’s easy to discount what you have and focus on what you don’t, but thinking about these folks makes me more grateful for what I do have.

I’d be surprised if I’m alone in feeling this way. Do you feel envious? If so, how do you deal with it?

Lifehack Mistakes Thanks Useful Tools | moore |

AI Can’t Care

I saw one post recently discussing how AI can’t substitute for judgment. There are many others if you search. And they all make an interesting argument.

But to me what feels more true is that AI can’t substitute for caring.

AI doesn’t care if the answer’s right or wrong. It doesn’t care if you were led down a rabbit hole only to find a dead end. It doesn’t care if a reader wasted their time or got a response that doesn’t actually address their question or need.

However, AI is good at giving feedback, checking details, and letting you create more quickly. AI should be used to help you draft but never publish. Use AI as a thought partner, a research assistant, someone who can help give you synonyms, reword a tough passage, review your work; but never take something AI creates and just publish it.

Why? AI can’t care.

But caring about your reader is the root of communication.

You can feel it when someone doesn’t care about their audience. We’ve all seen those LinkedIn posts full of emojis, or blog posts that have a smell that screams AI. That doesn’t mean the concepts explored are useless. It doesn’t indicate that the poster is incorrect. It doesn’t mean the post is not going to get engagement.

A post that AI creates may get seen or shared. But it also devalues the reader. When someone does this, it means they don’t give a damn. They don’t care enough to realize what they’re putting out there is not valuing their readers’ time.

Why would you pay attention to someone who doesn’t care about your time?

Everyone who reads something online, whether they scan it or read it deeply, is giving you the precious gift of their time.

Even oil we can make more of. But not time.

So use AI as a tool to help you move faster. But don’t forget to care about what you publish. That means carefully reviewing AI output to ensure correctness.

Otherwise you’re burning your reader’s trust.

AI Content | moore |

Meetings are forcing functions

A recurring meeting serves as a powerful forcing function for long-running projects.

Many organizations face a common challenge: a complex project that requires effort and perspectives from multiple people, moves through definition and execution phases, and unfolds over weeks, months, or years. But one where the tasks to accomplish the project are not anyone’s full-time job.

Everyone has other obligations, fires to put out, and emails to answer. It’s easy for long-term strategic, high-impact work to sink to the bottom of everyone’s todo list.

One effective solution is to schedule a standing meeting. Whether in person or video, it doesn’t matter. The key to making progress is maintaining an agenda and, critically, opening each meeting by reviewing the to-dos from the previous one. This creates pressure on everyone to make progress. When people know they’ll be asked “what’s the status of X that we talked about last week?” at an upcoming meeting, it is easier, though not easy, to carve out time for that work amid the daily chaos.

This approach works across organizational boundaries too. If you’re a consulting firm, a regular cadence of meetings with your client is especially valuable. You’re  motivated to deliver., but people on the client’s team may be less so. A meeting where you consistently show progress while they haven’t made any creates gentle but real accountability.

If you’re managing a large, complex, multi-person effort, consider the standing meeting. As far as schedule, weekly, bi-weekly, or monthly all have worked for me in the past. Pick whatever fits the urgency.

Use a meeting as a forcing function to ensure people actually make time to move the project forward.

Consulting Tips | moore |

The Nepotism That Isn’t

This is something I’ve learned over the years, having watched it happen at company after company. I thought it was worth documenting for future me.

When I was a young programmer in the early 2000s, I was at a consulting company that took on investment money and brought in a new CEO and new executives. The original founder and other members of the old executive team were slowly pushed aside.

I remember watching the new executives bring in their own people, and I remember thinking: wow, that’s really crappy:

  • They don’t want to leverage what got us here.
  • They don’t value the current talent.
  • They don’t understand the company.

And frankly, I thought it was nepotism. New folks were hired into the company at a high level because of who they knew.

Boy, was I wrong.

The honest truth is that running a company is hard. Coming in to run a company is very hard. You’re typically brought in precisely because what worked before isn’t working anymore. (There’s the occasional case where someone is ready to leave for personal or professional reasons.)

I don’t think most VC firms or investors have any desire to have friends or former colleagues running their portfolio companies. They would much rather those companies be doing great and not requiring any additional time or thought.

But that doesn’t always happen, and sometimes a company needs some attention.

When you bring someone new in at the top, you often cast a reasonably wide net. An executive search for a new CMO, CRO, or especially a CEO starts with your network, but search teams also look in other places.

However, the executives who are brought in don’t always have the same scope when it comes to hiring the people right below them:

  • someone to lead demand generation
  • a new engineering manager
  • a VP of something

So what do they do?

Think about it: what would you do if you were under significant pressure, still getting up to speed, and needed to find someone you could trust to execute on a vision you were still figuring out yourself?

I know what I would do. I would tap my network. I would go find people I’d worked with before, people I trusted. There are people I can think of right now who, if I had the budget, I would hire without question. There aren’t many people I trust wholeheartedly, but they exist.

That is what I was watching play out back in the early 2000s, without understanding.

I was seeing executives come in under real pressure to deliver, still learning the environment, and doing what any human being would do: hiring people they knew, people they trusted.

Jobs Startup | moore |

Reflections from the February AI Builders Meetup

I just went to the latest AI Builders Meetup and it was really fascinating. It reminded me of the years of the Boulder-Denver New Tech Meetup, where there was so much energy in the room. There were people who flooded the meetup talking about all of the interesting things they were building.

This meetup was similar.

There was also the same kind of supporting infrastructure with companies willing to throw around money. For instance, at this meeting, there was plenty of beer and pizza. It was at Founder Central and there was plenty of space.

I have been part of other meetups where it’s very, very hard to find space or money for pizza. AI is such a hot topic right now that it is relatively easy to find space and sponsors, such as service providers or VC firms who want to pony up.

There were over 500 RSVPs. I don’t know how many people attended, but there were hundreds of people there.

As far as the presentations, they were demos and varied quite a bit.

Some were over my head. For instance, the folks that use the transformer architecture to predict and build audiences for drug trials. I understood the general concepts, but some of the technical details went beyond me. Still a really cool technical overview from Branchlab.

There was also a presentation about building personalized apps using Wabi.ai. I thought that was interesting but a little bit hard for me to understand why people would care about building their own apps. But I was never someone with a personalized ringtone or even stickers on my laptop, so I might not be the target market.

The next presentation was a demo from FreePlay, one of the sponsors. They were filling in for a talk that bailed; it wasn’t intentional. They covered how they built an agent to help people improve their prompts inside their eval system. They shared a Notion doc which had some learnings on building this agent, which were pretty useful. I think one of the key points that I took away was that cross-model optimization is really hard. Each of the models has their own wrinkles and idiosyncrasies, and it’s really hard to build cross-model applications or agents. You can work around some of the issues by aiming for lowest common denominator.

Another presentation was about Mai-Tai, an open source framework which lets you access coding agents from your phone. This was kind of a cool, interesting way to use a phone before Claude’s or OpenAI’s tools existed. It seemed really developer-focused; they’re looking for PRs.

The final project was really interesting to me. It was from one of the founders of Slider. It showed how you can automate constraints around agents and how that leads to better outcomes. In this case, they were doing that with design systems. They built a way to have an agent have ground rules and understanding around building applications with a certain design system, like a Workday application.

This was interesting to me from a number of perspectives. The first is that I’ve been thinking a lot about authorization as one of those guardrails and how that interacts. The second thing that struck me was when he talked about compilation checks versus runtime checks. Runtime checks are better-crafted prompts, and compilation checks are enforceable, deterministic guardrails like linters or authorization. He kind of didn’t want to give away all the secret sauce, so he didn’t dig into all of those deterministic checks. But to me, that seems like it’s where we’re headed. With this approach, you get the best of both worlds: the non-determinism to let an agent accomplish ill-defined tasks, and good guardrails to keep it from doing things it should not.

All in all, it was a great meetup.

AI Community Meetup | moore |

Top Professional Accomplishments

Not to get maudlin, but it is fun to think about accomplishments over the years. The days are long, but the years are short, and I can’t believe I’ve been working in software development for more than two and a half decades.

My top professional accomplishments include:

  • Writing a book for a known publisher
  • Co-founding a startup that is still alive and kicking (5+ years after I left)
  • Running my own consulting business for about 8 years, and making a decent living from it
  • My time at FusionAuth; I’ve worn a bunch of different hats with real impact on the direction and culture of the company
  • Presenting at marquis conferences like Identiverse
  • Co-organizing the Boulder Ruby for about 5 years
  • Supporting the website of one of the biggest sporting events in the world
  • Keeping this tech blog running for over 20 years
Consulting FusionAuth Lifehack | moore |

MVP = embarrassing

This is a re-post of an article I wrote in 2019 for the Gocode Colorado blog which is no longer available. Thank you Wayback Machine!

“So, we need this feature to work, and it has to tie into this API, and we should put it all on the blockchain.”

“What about feature X? And we need admin screens, and roles and groups for different kinds of users.”

“You’re right! Let’s add those to the list. We need to make something we’re proud of.”

I heard some version of this conversation over and over again at my last Go Code Colorado mentoring session. And I sympathize with the sentiment, I really do.

But instead of hitting it out of the park the goal should be to create a piece of software that achieves the bare minimum, or a minimum viable product (MVP). With a high-risk venture team members should aim to show features to the end user as soon as possible, and to let their interactions guide the future of development.

It’s far too easy to get distracted by all the possibilities and build features that won’t be used. Even worse, developers may compare their application to other applications they use and find it wanting. The level of polish an MVP needs is far lower than a production application like Gmail, but because you use production ready apps every day, their UX and polish can feel like a requirement. Building features or adding UX polish can delay shipping an MVP. You want to wait until you are “ready”.

You are never “ready”, my friend.

If you’re not embarrassed by the first version of your product, you’ve launched too late.

– Reid Hoffman, LinkedIn Founder

Keep your focus not on the software but on the user.  Spend time talking to your target market and putting either mockups or working code in front of them as frequently as you can. Finding these people is another blog post entirely, but hopefully, you have some idea who they are and where they hang out.

It can be scary to put what you’ve built in front of people. It’s often much easier to sit back and build new features than it is to ship. I have felt it myself–as a startup co-founder, I built a web app that I was, frankly, embarrassed to show potential customers. It was missing features I considered crucial, was full of holes and bugs, and didn’t have a consistent user interface.

But showing it to potential customers early and often was the best choice. They pointed out missing features and also explained what was unnecessary. We got great feedback and I was better able to understand the types of problems the customer faced.

There are many ways you can show potential users what you are planning to build or are building without having a fully finished product.

  • You can show them mockups, either a paper draft, a series of powerpoint screens or a clickable prototype (Adobe XD or Balsam IQ are solutions). This is the cheapest way to get feedback because changing a screen in powerpoint is far easier than changing a screen in code.
  • Enroll potential customers in a beta program. Customers are more forgiving if they know this isn’t the final product, and they’ll give you suggestions. Don’t take each suggestion as truth, but do try to find out what problem the suggestion is aiming to solve–that’s gold. Offer people in your beta program a discount when you start charging–that gives them the incentive to give good feedback and can seed your customer base.
  • Build out mock features. Instead of building a full file upload facility, I have added a screen to an app with a link to “email us to add a file”, and fulfilled it manually. If enough people mailed a file, we’d know we needed to build the feature.
  • Have someone walk through the application in a video chat (using GoToMeeting or Zoom). Similar to a beta, people are more forgiving when they are shown something and you will be able to see where issues arise (“how do I do task A?”). This experience can be humbling and frustrating at the same time, like watching this.

When building an MVP, use tools you know. Whenever I’m working on a project, I balance technical risk and business risk. If you’re building a true MVP, the business risk is very high, because you don’t know if the market actually exists. Therefore, minimize the technical risk by building with what you know.

But wait, aren’t customers expecting a polished application?

Some may. Early adopters who are looking to have a problem solved often can look past the rough edges and see the potential. It also depends on the domain and the competition. For instance, if you are starting an Instagram competitor aimed at consumers, the quality bar will be pretty high. If you are building a scheduling tool for tattoo parlors and your main competition is a spreadsheet, a web application built with any modern framework will likely wow your potential customers. It’s also important to show your customers that the application is continuing to improve–that will make them more forgiving of the inevitable issues.

You’d be surprised by how forgiving people can be, especially if you are building something to help them do their job better. Remember, if you aren’t a little bit embarrassed when you show someone your application, you should have shown it to them sooner.

Additional resources:

Startup | moore |