Everyone Forgets Technical Research

You’ve just finished a round of research for a new product or feature and have that aha moment. Maybe you have ten of them. You’ve identified the problem to solve and know exactly what to build. 

What do we all get fired up about next? BUILDING.

You’re not alone. Every one of us wants to start building that next product or feature as soon as we’ve finished our customer research.

Here are the issues I always seem to hit myself when I jump right into building that next product or feature:

• Delays, delays, and more delays – what was supposed to take 3 weeks has suddenly taken 3 months.
• Major technical hurdles that weren’t anticipated which slow down Product development and may even force development to stop.
• Building too much too soon and ending up with a product that’s full of bloat.
• Engineering spends too much time on the wrong things, and the features that matter most are light compared to parts of the product that matter least to the customer.

When I’m at this point, momentum slows down, I start second guessing what I learned from my research and I fall back into old patterns of just building what I think is right: Ideas that aren’t backed by research. I may have completed my customer research but I’ve missed another critical area of research.

At that point, my new product is dead on arrival and I just haven’t admitted it to myself yet.

This is where we all get frustrated and start feeling like we should give up.

You can avoid this situation, it’s entirely preventable.

There’s a step that most people don’t take. I’ve missed it many times myself. It’s not sexy. It’s not easy. It won’t be fun. But it’s crucial. It’s the key to anticipating potential delays, technical considerations and figuring out exactly what’s most important to build first.

Earlier this year, we shared our Early Access Liftoff process with you on a new product we’re building – in case you missed it, here are some blog posts detailing what we did and how you can do it too:

• How To Create Early Access Surveys For a New Product Or Feature
• Early Access Email Scripts For a New Product Or Feature
• An Inside Look at a Successful Early Access Survey

After we finished our Early Access Liftoff, we could have jumped right into building the product. It’s so tempting to rush right into code. And at first, that’s exactly what we wanted to do. 

After fighting our inner demons and winning, we took the next critical step: Technical Research.

Before you start writing detailed specs, before you start designing, and before you write a single line of code, Technical Research will bring to light almost every obstacle you’ll encounter as you build your Product.

You might think writing code first is faster. After all, you’ll have code and be one step closer to a launched product. But it’s not.

Technical Research helps you get alignment with your engineering team. You get to have the hard discussions about technical trade-offs, upfront. Before your engineers jump into code and have to make those decisions on their own.

You’ll make important product decisions that impact not only the first version of your product but also the future of it. Plus, you’ll actually launch on schedule and not run over budget.

How to run Technical Research

Technical research tells you how long your product will take to build and how to build it. It gives you clarity. You’ll get an understanding of exactly what you’ll be dealing with ahead of time before you’re actually writing code for a product or feature.

Here’s exactly how I implement technical research in three steps.

1. Build your Technical Research outline

In order for Engineering to start their research, they’ll need to know details about the product. At this early stage, you don’t need full detailed Product specs.

Your job is to feed as much information as necessary to Engineering so they can investigate how they’re going to code and communicate trade-offs with you.

The outline should be a short summary of what you’re looking to create, including required features and functionality.

You should also provide guidance on what matters most to you (and customers).

What’s the core problem you’re looking to solve, and how do you plan to solve it? What are the most important parts of what you’re building?

Engineers are most effective when they understand the problems their code will solve for customers. That’s where the product research you’ve already done comes in. The best technical research outlines include details from customer development. These details help engineering understand that there are real human needs of your customers backing the product decisions you want to make.

Once your outline is done, share and discuss it with Engineering. The best way to set a solid foundation of research is to do this in a document and through a follow-up meeting so everyone can get on the same page.

The outline should be no more than 1-3 pages long. Here’s a template we use for our products:

• Research findings – high level summary of the research you did and key findings.
• Product overview – a brief description of the Product.
• What needs to be included – the Product “must haves” required to make your idea work.
• What doesn’t need to be included – what isn’t important (yet) to add to the Product.
• Open questions – questions you have about how to build the product.
• Initial mockups – if there were any quick sketches or mockups created during research or to help explain the product, those are shared via the document.

2. Give engineering time to research!

Engineers typically build according to spec. Oftentimes, Product doesn’t know the workarounds or better yet, more efficient and faster ways to build something. But engineers do. That’s where technical research comes in.

Technical research gives engineers the space and time to think through the best way to build the product before they create a plan and start programming. Instead of jumping into code, they have the opportunity to consider the different routes they could take and the tradeoffs of each.

The research should take a few hours to a few days, depending on the complexity and size of what you’re building. These few hours will pay back tenfold in time and cost savings as you build your Product.

Engineering research will give you visibility into these key areas:

• Initial trade-offs – what are the technical considerations for creating the desired product experience and what are the workarounds?
• Speed – approximately how long will what you want to build take to make?
• Decisions – technical and product implications that you need to decide on before you build. These decisions should be made early on to avoid going down the wrong path or wasting time.
• Risks – potential barriers and problems that have been identified that will slow you down or trip you up, and how you can avoid them.
• Resources – what are the resources necessary and are they available to build it?

Send this list to your engineers as a starting point of the types of questions you’d like to answer during this round of technical research.

3. Discuss findings

Once engineering has completed their research, it’s time to have a discussion about the key discoveries that were made. 

Depending on the scope of the project this can be a quick discussion with an engineer or a write-up that leads to a discussion between several Product and engineering folks.

The goal of discussing research findings is to determine the best approach to building the first version of your product/feature diligently. This is the last step in the technical research process and it’s where you’ll learn the most.

You can figure out exactly what’s going to be time consuming for engineering versus what’s going to be relatively easy to build. You’ll get clarity and can make much better Product decisions by taking the time to discuss findings and have engineering explain what they’ve learned.

This conversation is your chance to dig into the specifics and ask questions. There may be some more research that has to happen as a result of the conversation to ensure the right decisions are made before you start building. You may also learn that you have to change the direction of your product because of barriers or constraints that you didn’t know about previously. 

All of this saves you time, and the limited resources you have from being wasted on product development that doesn’t move the needle.

Here’s a summary of what we included in our technical research outline for our last product:

• Research findings – we dug into the open-ended responses from the surveys and interviews we did to find the key points relevant to the initial product we wanted to build. We summarized these in 2 long paragraphs.
• Product overview – we gave a 3-paragraph description of the product.
• What needs to be included – we explained the one core feature we need to get right at first and discussed what’s most important for the user to have for the user experience.
• What doesn’t need to be included – we mentioned what features we want to build later, but don’t plan to for the first version of the product.
• Open questions – we listed seven questions we had for engineering, as well as a few we haven’t answered yet about how the product will function.
• Initial mockups – we provided initial wireframes to help illustrate the core functionality of what we’re building.

Every single time I’ve done this, I’ve had a big learning that saved me months of wasted effort. It doesn’t matter how large or small the product or feature initiative is, there’s always a technical problem that gets uncovered during this research project.