Make The Name Stick & Win Big!
Welcome to the front line. The product development trenches. Priorities are oscillating. Code is releasing. Objectives are splintering into teams and tasks. Hold on. We’ve got a project to manage.
As of today, I’m actively working on 2-3 projects, all in different stages of development and ranging from small to big.
I’d like to talk about one project that’s now reaching it’s release date.
As owner, I was tasked to define the goals and plan for how the team would distribute and tackle the work over the coming weeks. The usual stuff.
With any kind of knowledge work, there’s many micro-decisions made, committed and changed daily. Most of them don’t matter much. But during the course of this particular project, I discovered one small thing that has disproportionate leverage.
The Project Name.
When I took ownership of this project, it had a drab, uninspiring, unmemorable name, (I literally can’t remember it), something like “Update recommendation system to allow for new content”.
It was sick, dying, and no one wanted to touch it, let alone get excited to work on it.
As I drafted up the initial plan, and dug into the background of the task (talked to stakeholders, poured over research), I was happy to discover that it wasn’t as feeble as it first appeared.
The project simply aimed to show the right content to the right person. Think how Netflix adapts it’s homepage based on your tastes.
That’s obvious value for the customer, and an easy sell. That’s something I could work with.
When I published the first draft of the product spec, I renamed it to “Perfect Program”. I didn’t think much of my decision, and moved onto the next steps for the project.
I won’t go into the specifics of naming here, but I can share a few of my thoughts as to what might make a good name.
The response from my team was mixed. Some didn’t know what Perfect Program was, and were confused when I started to reference it. Others thought it sounded corny. Most didn’t notice.
But slowly, over a few weeks, the name stuck. People started using it.
It ran of the tongue easily enough, and soon everyone not only knew what the project was, but were breezily referencing it in conversations. In meetings, over whiteboards, slack channels, syncs, standups, asana projects.
The project was no longer “Update recommendation system to allow for new content”. It was Perfect Program.
Aside from a catchy name, another interesting thing happened.
Since this was a more involved project, with fuzzier goals, the detail of the feature changed quite a bit as we started designing the flows and interactions.
But the name stayed the same.
In fact, the name started to grow supernatural powers, and guide our discussions, designs, and plans.
Why?
I have a hypothesis. Since “Perfect Program” neatly encapsulated the benefit to the user, as well as the technical goal of the project (a recommendation engine that works), it anchored the team and prevented us drifting too far or adding too much scope.
In other words, the name started crafting the product. Or the team started crafting the product after the name.
Imagine an imaginary project to improve a sign-up flow. There’s a million ways you might attack that problem. Some solutions might be successful, but many might lead you down the wrong path, add unnecessary complexity and take longer to ship something inferior to customers.
Instead, why not align the team around a memorable name like “Simple Signup”. The project goal, user benefit and even primary design principle are baked in. If developer B thinks its a good idea to build in a QR scanner, you might casually remind them that our job is to “simplify” the interactions for our users.
A good name also places you in the enviable “high ground” position.
When I was asked to describe the ‘point’ of the feature, I leveraged the name itself. I said something like, “based on data, our users are struggling through the onboarding process, and are forced into the wrong programs (too difficult etc). We want to find out what they like, and then show them content that’s perfect for them and their needs.
Amazon uses a similar process when developing products or features. They “work backwards” from a press release. This is a great technique to force your initiatives to truly be customer centric, rather than cranking out another feature and bolting on the customer benefit post-release.
I view a good name for a feature as the tip of the iceberg. It should summarize that imaginary press release, and the narrative should naturally flow from it, like it’s the first sentence in a story.
To summarize, a strong internal name for a product or feature may help owners in the following ways:
• Guides product teams to stay on track, acting as a project-level north star
• Saves you time. As owner, you’ll spend less time communicating the same thing to different groups.
• Compresses a lot of background information into a snappy name that can speed up conversations and brainstorms.
• Forces you not to be a lazy thinker. Jeff Bezos panned powerpoint “because he was increasingly frustrated at the lossy nature that medium.” If you can neatly describe the project in a few catchy sentences, it’s a strong, hard to fake signal that you understand the problem and what to do about it.
• Defends the project by taking a super strong, high-ground position. You are clearly communicating the value of the initiative, rather than the nuts and bolts that geeks care about.
• Potentially guides and aligns future marketing efforts to product goals, since they both share the same foundations. If your name is really good it might even be user-facing!
• Fuels morale, like a good team name might at a sports day. A month or so in, we stumbled upon an idea for an improvement. The spin-off feature would enable customers to follow multiple, or no programs if they wished. The lead dev named it “Flexible Following”, half tongue in cheek, but it was perfect! I was stoked, and the name stuck.
Ultimately, all these factors may help your team produce a better product. The name becomes fulfilling.
It goes without saying, these benefits should also apply to strategy higher than project/task level. Mission statements, quarterly objectives could all benefit greatly from being “really concise and memorable” in order to build shared understanding and context throughout the org.
Next time you have the opportunity to name an internal project, make it stick!