On serendipitous discovery vs. careful planning in product development

If you are working in a problem space that is new to you (or perhaps even to the world), attempting to come up with detailed plans up front is likely to be a huge waste of time.

But does that mean that in the early stages of a project in unknown terrain, you throw spaghetti at the wall and see what sticks? Not quite.

Instead, this is what you can do: Work in very small chunks, relative to the resources and time you have available. In the context of a solo developer working on a side project, this might be a couple hours of time per experiment; for a company with sufficient budget… it may be a couple weeks of development time.

Don’t stop at one experiment, though. Build a small portfolio that aims at different angles of the problem space you’re exploring. Limit the size of that portfolio based on the time you have available; there’s no point in putting ten experiments out in the world if you only have enough bandwidth to support feedback on three of them.

From there, share the work and try to see what captures the interest of the audience you’re trying to reach. But don’t push too hard, especially if you don’t know the people in that space yet. Spend most of your time listening, tune your experiments based on what you’ve learned from observing the people in that space, and don’t be afraid to abandon the experiments that you know you got wrong, or that didn’t bear fruit.

Over time, a combination of luck and learning, along with a whole lot of hard work and patience WILL generate some sort of spark. Once something starts getting traction, then do more experiments in that area… until you start to see the faint pencil sketches that outline the space you’re in.

Once you get there, then it’s time to gradually shift into a different way of working. Now attention shifts from drawing the outer lines of the figure to filling in the details.

A steady and growing stream of people using your software, responding to your writing, whatever… is a sign that you’re starting to produce disproportionate value. Revenue is the strongest indicator of value, but sharing, repeated visits, etc… all of these tell you that you’ve built something worth fine-tuning.

When you reach that stage, it’s time to start partitioning the space: Maybe you still reserve some of your time for free-form experimentation, but that becomes 20-30% of your effort. 70% of your time shifts to operating and tuning the engine that you managed to create.

At this point, yes, careful planning starts to matter… mostly because you actually have the feedback loops to support it! Wild guesses tighten up and become testable hypotheses — return on investment is actually considered before work is done, etc.

The simple starting point for tightening up focus is probably to start with AARRR metrics on the product side (Acquisition, Activation, Retention, Revenue, and Referral) — and throughput metrics on the development side (average cycle time for delivery, average # of WIP tasks, minimum response time, etc.). From there, you need to specialize for the industry you’re in.

The challenge we have in the software industry is that for both product designers and software developers, the folks who are good at the exploratory stages of a project are not usually the same folks who are good at the “measure twice, cut once” way of thinking. And yet any successful project will go through both of these phases, so some sort of attention ought to be paid to the crossover point.

I don’t have a direct solution to that problem, but it’s definitely something to think on for business people, product designers, and developers alike. This is a submarine in the waters that has sunk more projects than any of us would care to admit.

PS: It’s worth noting that none of these thoughts are original. They’re all found in Agile, Lean, and various other modern product development methodologies. For my part, I’d say that those who want to dig deep ought to read Reinertsen — because he takes an economics focused view of the problem and that leads to some unique perspectives.


Shipping code is not the main goal of software development

Do you know how to write code?

How about beautiful code?

Are you proud of your craftsmanship?

Of the maintainability of the systems you build?

Do you search for the best technologies that allow you to write code with speed, confidence, and elegance?

Do you spend a lot of time talking to other programmers about what it means to write great code?

Have you mastered the many development tools you use day to day?

Are you great at text editing?

Great at algorithmic analysis?

Great at performance optimization?

Are you some sort of hero to the open source community?

It’s worth remembering that you can say “yes” to all of these questions, but still not know the first thing about serving customers well. In other words, you can be very technically skilled — but yet not know how to properly solve human problems with software.

To get good at producing software that is actually useful, you need to spend more time thinking about humans than you do about computers.

How do you quickly understand the needs of someone who may not know how to clearly communicate them to you?

How do you work with the budget and resources you have rather than the ones you wish you had?

Once the software ships, how do you prove that it’s doing its job well?

How do you gain the required trust and respect that’s needed to be given meaningful decision making power around the projects you’re involved in?

How can you balance the needs of many different stakeholders while still putting the people who are affected by your software first?

The only successful software is the software which ships, solves the needs of the people who use it, and leaves the world better off than it was without the software.

Always remember that raw technical talent is about 20% of the problem, and that if you are spending 80% of your time focusing on honing those skills — you are probably doing it wrong!


On changing tech stacks to increase programmer happiness

For the most part, if the happiness of a development team is tied to the specific technology stack they’re using — that’s a sign of an unhealthy team. Changing tools as a morale booster seems like a shortcut to avoid dealing with a much deeper organizational problem.

There are of course exceptions: tools that you spend most of your time fighting against create enough friction to severely limit productivity, which in turn makes people unhappy. Tools that have fallen far enough out of popular use to the point where there is no longer a critical mass of people using them or supporting them can lead to a harmful form of isolation.

But changing tools because they’re no longer cool or exciting? This is vanity at its highest level, and implies that the technology is what matters… not the product or the company or the customers. The antidote is to go deeper into this side of things: to shift attention away from the tech stack and towards the product. To learn supporting skills in business, design, customer support, etc. To build interesting and useful internal tools to help everything run more smoothly, etc.

Of course, programmers will be programmers. Some limited investment and exploration into new toolchains is a good idea, but you don’t need to “switch” in order to do that. Just set aside a small percentage of the time in a week for casual experimentation, and see where that leads you.

When the time comes where a tech stack change can be directly tied to a clear benefit for the customer or to the business… you’ll know it. Until then, there’s no need to rush.

How to reach me during “Quiet August”

So that I can focus on the essentials of life and work, I am taking a break from social media (particularly Twitter) between now and September 6, 2016.

I’m doing this in part because I want to reconnect with people and projects that need some love from me… the last year of book writing has taken its toll and it’s time for me to create some space for other responsibilities.

But I’m also taking a break because there is a lot that can be learned when you step away from the daily buzz of social media to find some deeper signals.

I’m not dropping off the internet in August… quite the contrary in fact: I’m just switching focus to a handful of more slow-baked activities.

If you want keep in touch with me throughout August, here are some options:

  • Email me! My inbox is open to everyone for questions and conversations. Send a message to gregory@practicingdeveloper.com.

  • Join the Programming Beyond Practices newsletter. I’ll be writing more essays there, with my newfound free time.

  • Join the Practicing Developer’s Workshop — This private learning space is where I will be spending the bulk of my online time.

  • Follow this blog. I’m not sure how much I’ll post here, but I imagine at least some stuff will surface.

No matter what, I’ll be back to Twitter in September. I really want to focus on making what I’m doing there above and beyond what you’d expect… and I have ideas for how to keep pushing the limits of producing good materials in tweet format. But for now, I want to get down in the dirt with the people and projects that matter most to me… and have a quiet August.

See you again soon!!!

Practicing Developer’s Workshop: Phase 2

For the last half a year, I’ve been running a dedicated learning + discussion space for software developers from all different backgrounds, called “The Practicing Developer’s Workshop”. Despite its relatively small group of active members, I have had some of the best professional conversations of my life there.

It is in part a place where I can get together with my friends and supporters, and in part a service supported by paid subscriptions.

We do everything via Slack. And I know what you’re thinking …doesn’t everyone already have like… five hundred Slack groups they’re a part of? Well, yes they do. But we do things differently.

The thing that separates the Workshop from other groups is that it’s well managed. There are clear guidelines for how to have productive conversations, conventions we use to remind each other to be kind or to slow down when we’re talking past one another, and a whole host of other things that make it very different than any other place you’ve ever seen online before.

This is something that is easier to show than explain, but you can get a rough sense of what we’re up to by reading our Newcomer’s Guide and Membership Benefits.

On top of being a great place for conversations, there are a bunch of structured activities as well: study sessions on specific topics that interest the group, reviews and early access to all the learning materials I’m working on, and collaborations with special guests.

The last couple months have been a bit on the slow side because I was deeply buried in writing my book. But now things are gradually picking up again, and I am finally ready to start asking new people to come check it out.

You may have already added yourself to the waitlist a while back, and if you did, you’ll eventually get an email from me (but be warned… there are literally hundreds of people on that list, and I’m only going to reach out to a few per week)

Whether you had signed up for the waitlist or not, here is how you can get yourself moved to the front of the line: Send a direct message to @practicingdev on Twitter (my DMs are open to all, not just those I follow), or email gregory at practicingdeveloper.com with a short introduction about who you are, and what you are currently working on and/or studying.

NOTE: The cost of a paid membership is $30/month, but all newcomers are given a free ten week visitor’s pass to see what the Workshop is like. There are also a limited number of no-fee scholarship seats available for those who require financial assistance.

On mentoring others while staying on top of your work responsibilities

The short answer is that it is very difficult to teach and work at the same time. So much so, that many attempts to do so end in failure.

Of course, that doesn’t mean that people can’t learn on the job. If your goal is to mentor someone while also doing a good amount of work yourself, then the best way is to demonstrate by example the kinds of behaviors, habits, and skills that you hope others on your team can learn.

The challenge in using yourself as an example is that your focus will naturally turn towards the things that matter most to someone at your level of experience, and those things may be hard to relate to for someone who is comparatively less skilled in those areas.

So instead of focusing on what is interesting to you, think of what matters to the person you are trying to mentor. To figure this out, you can also spend some time observing how they work. It should be easy to identify things that they struggle with that you have mastered a long time ago. By looking for opportunities in both your work and theirs to provide mini-lessons on those topics, you can get a big result from a small amount of effort invested.

All this said, this sort of on-the-job learning has its limits. There are many concepts that developers must master which require dedicated effort. This means either being patient and waiting a long time for the person being mentored to figure it out themselves, or cutting back work responsibilities for the mentor so that they can go deep into training around a particular “hard topic”.

Usually a spiral approach is best. Do some training alongside your daily work responsibilities, but maybe a few days per month set aside for deeper training activities. Each “big lesson” paves the way for tons of little lessons that can be fit into the daily work schedule.

The danger is when you try to mix the two, because you end up with both half-done lessons, and half-done work!