How do you know if you have validated the problem space enough to start dedicating engineering resources to building out the product?

This is hard! For me, it's a mix of having a good understanding and confidence that you have 

(1) a clear hypothesis that you can test with a minimally viable product that is shaped by data and customer/market research,
(2) confidence that you have a potential solution that can prove the hypothesis correct, and
(3) an understanding of the risk and opportunity for building that solution, including the time it'll take to build, the availability of users willing to try your solution.

When in doubt, it's always a helpful rule of thumb (in my opinion) to simplify the scope of your solution as much as possible, to both reduce engineering time/complexity AND to not squander the opportunity cost of shipping too late (see the Reid Hoffman quote question posted as well!). The hardest one in my opinion is 1 - making sure that you get down to the real essence of an unmet customer need and being incredibly clear and specific on how you think your product can solve it, and how you will know.

Before investing in engineering resources you want to build conviction around the following:

1. Is there a market need? Are you fulfilling a true gap in the market?

2. Do you have a differentiated vision to deliver on this need?

3. Is there willingness to pay? 

4. Does the business model make sense such that you see a path to ROI for the business?

5. Is there a clear route to market (you know how to sell / acquire customers)?

6. Does your business have (or plan to have) the capabilities to deliver on this product (ex operational, technical or other expertise) such that it is strategic to expand in this direction?

Overall you want to be able to articulate what the investment unlocks for the company and how.

For a new product in a new market, I don’t think you can ever validate the problem space enough. Once you have reasonable confidence that the users (and buyers) exist for the problem space your product tackles, and there are viable ways to create a business out of that solution, the best next step is to involve engineering to build a prototype of the solution. Then you can test that prototype with a representative sample of the expected user base to get early feedback and iterate on building out the product and grow the business.

For 0-1 products, involving engineering early as a partner to the overall product definition and development process is best, so you can iterate together on building the right product for the right audience.

To ensure that you are investing your resources wisely, it is critical to have a high degree of confidence in the problem you are going after. You do not want to spend engineering resources on a problem that may not be large enough or is technically not possible to solve. Here are some key indicators that can signal you are ready to allocate engineering resources to building out the product. However, it's important to continue validating, testing, and iterating on the product as you move forward to ensure that it continues to meet the needs of your target audience.

• Market opportunity: You have conducted market research and have a clear understanding of the market opportunity for your product.

• Understanding of the customer problem: You have a clear understanding of the problem you are trying to solve, the target audience, and the key pain points that need to be addressed.

• Validation from potential customers: You have received validation from potential customers that the problem you are solving is important to them and that they are willing to pay for a solution.

• Clear product vision: You have a clear product vision that is aligned with the problem you are solving and the needs of your target audience. This includes a clear understanding of the features and functionality required to solve the problem.

• Defined product roadmap: You have a defined product roadmap that outlines the key features and milestones required to bring the product to market.

• Resources and budget: You have the necessary resources and budget to support the development and launch of the product.

• Competition: You have a clear understanding of the competitive landscape and have identified how your product will differentiate itself from the competition.

Validating the problem is of course a critical step in building a great product. A couple of signals to look for

• Do you have a clearly articulated problem statement you are trying to solve
• Did you conduct robust user research to narrow down your problem statement to know what you would be solving? Users' desire to buy and use a product to solve the problem is the best signal you are looking for to keep marching forward
• Business viability of the problem statement - This reflects the market you are playing in, and the business model you would consider. Have you estimated the cost of development and compared it to the potential return on investment? For B2B companies a great way to validate this is by getting Letters of Intents (LOIs). Its a nonbinding document saying the customer is willing to pay for it
• Lastly, I would say you should have a proof of concept in Figma or some prototyping tool and put it in front of customers. This step is critical because you will truly know what works or doesn't work. You can also start small with 1 engineer and slowly grow the team. 

Hence, before you put a ton of resources, try to take above actions. Once you have conviction, start small might teams who will build and iterate

Validating the problem space sufficiently before dedicating engineering resources is crucial. Indicators that suggest you are ready to proceed include: a clear understanding of customer needs, consistent feedback validating the problem, comprehensive market research and competitive analysis, alignment with business objectives, a potential market size and opportunity, confidence in achieving product-market fit, and risk mitigation through iterative learning.

By thoroughly researching the market, gathering feedback from potential users, and assessing the competitive landscape, you can understand the target customers, their pain points, and the viability of your product. Consistent validation from multiple sources strengthens the case for moving forward.

Additionally, aligning the problem space with your business objectives ensures strategic coherence. Evaluating market size, growth potential, and customer willingness to adopt your solution provides confidence in the market opportunity.

This is heavily dependent on the type of product you are building, but you can get very far with high fidelity designs and manually "hacking" things together. I worked at a company where we "generated" (hand created) an analytics report for a customer (who was actually paying us) once a month. It took an insane amount of time to create (20+ hours) but the feedback on both how to sell, and how to build our product from that experience were invaluable.

Start light: with high-fidelity designs and clickable prototypes. Once you have consistent signal from your ideal user persona saying that they would use the product if it existed, then get to work on a POC (proof of concept) only. Don't fully trust your customers just yet - you still need to prove that they will actually use it.

I believe all early initial engineering work should be treated as POC work. Piece together what you need to in order to get the validation that people will actually use it. At this point, you are building to learn, not to last.

Once you are starting to see usage and actual traction (and in parallel are having success in the market on positioning and selling), that's when the decisions around how to invest in engineering will come in. Again, this is highly dependent on the type of product you are building, but the biggest trap people fall into is focusing on scale before seeing any success.

Be scrappy at first, scale later. And build to learn.

I would start with problem, root cause, solution (aka RCA) and really understand the problem you are trying to solve with your product. Once you understand the problem and proposed solution, next step would be to validate it with customers. Customers' feedback is a good indication on whether you have a good product to address problem in the market. Additionally, you need to understand the target market and your competition in the space (how does your solution stack against competitors, what successes/failures have been proven in the market). Gathering all this data point, then decide if there is ROI in the solution you are proposing.

There are multiple things you need to get right before you start building a product, because the most likely outcome of creating one is that it will fail. To see an example of this you can watch this talk for how we did problem and solution discovery when creating Jira Product Discovery

• Validating the problem space is important. For that I think the recipe is pretty straightforward: talk to customers and prospects and let them guide you. It's quite important to go in there open minded about what you're going to learn - because there's a high chance that all the assumptions you made when going into these conversations are wrong, that people don't face the problems you thought they faced, or not with the intensity that you imagined. I'd recommend getting coaching from a user researcher on interview techniques - otherwise you can easily meet with 50 customers and learn nothing. It's one of the most important skills for PMs (and humans are naturally pretty shit at this so it REALLY takes coaching).

  • You want to land on problems that are felt very strongly and urgently by the people you talk to, and are pervasive.

  • By doing all this you'll form a view on who your target customer is - you want to keep refining this. And you'll identify potential customers you'll want to work with to shape the solution. We call them "lighthouse users" and it's who you would want to build the solution for: they feel the problem strongly, are crafty and have tried many different solutions to solve them to no avail, they're great communicators, easy to collaborate with and have urgency in solving the problem. Find them, and the rest of the journey will be much easier! Read this post to learn more about lighthouse users.

• But on its own it's not enough, there are other aspects to tease out.

  • You want to be clear on if there is a market - check out which companies play there, try to get a feel for their revenue and growth (there's a lot you can glean about that online); if you can, try to chat with investors who gave them money; understand the maturity of this market (early adopters, early/late majority, etc.).

  • You want to have a thesis for how you can win - e.g. do you have a distribution advantage, access to tech that's hard to reproduce, other? Note that the best product doesn't necessarily win distribution is going to be key to answering this question.

  • Distribution is super important and what will make or break your product. It's a good idea to validate demand and your ability to reach potential customers. In the past I've done this by creating and advertising a landing page on a website stating the problems and asking people to join a waitlist. That's how we knew we were onto something in the early days of Jira Product Discovery - within 3 weeks we had 3000 people on the waitlist (which contained zero information about the solution).

  • You need to have a clear answer on "why now?" - the problem needs to be felt really strongly and urgently by customers, maybe there is new tech opening new possibilities, maybe it's the right moment for your company to invest because of strategic reasons, etc. But you need to be clear on why this needs to happen now vs next year.

  • If you're in a bigger company with cash at hand, assess build/buy/partner opportunities - before jumping straight to creating something a new product: is there another company you could buy instead of building, and fast track everything by a couple of years?

• Even after answering all this I wouldn't jump straight into asking for engineers. I'd only do that if we're not clear the solution is feasible, e.g. if it requires new tech that we don't master. After problem discovery, don't skip solution discovery! There's a lot you can/should validate without writing code:

  • In the past I've shown people slides with value propositions and asked them to explain back to me how the solution would help them. There's a lot I learnt by doing that!

  • Create prototypes, in Figma, or live prototypes than people can play with. You can gauge the reaction of the people you give them to: if they "just" look enthusiastic about the solution you can throw it away. If they're straightaway asking you if they can please please please start using it tomorrow then you know you're onto something

  • Even if you ask for an engineering team: start with technical spikes and prototypes, the goal is to validate the solution solves the problem and is feasible. All of this will also help you refine your understanding of the problem space (problem <> solution work hand in hand)

You can also read more about it in the Atlassian Product Discovery handbook, that we wrote to help with things like this. Check out the "Ideas" section.