How to approach a new project

There’s a structure to executing any new project well. I don’t care if that project is a new business, a new feature, a redesign, or a new hire. All projects start with uncertainty and end with a finite solution, but the quality of that solution is determined by the process that got you there.

Mindset

Optimism is not your friend. If you have one takeaway from this entire article, that’s the one to remember. Optimism has its place and I’m not saying that your goal is to bring everyone down, but I see optimism play a destructive role in the steps ahead. Usually, it’s used to skip several steps, which will lead to a team that isn’t aligned at best and a terrible solution at worst, and it’s usually going to be the latter.

Your goal is to disprove your assumptions, not to prove them. This means that you will both double check the accuracy of your assumptions, as well as the value of them. You won’t stop at one solution because you’re not convinced that it’s the best one until you evaluate others. You’ll do more experiments than seem necessary in the prototyping phase and you’ll measure as much as possible in the MVP product.

If you don’t feel comfortable with this mindset of being pessimistic and always searching for what might be wrong with your plan, then please get comfortable with it. Meditate on it, ask around, do whatever you have to do to get on board because this mindset is what creates quality solutions.

Define the Problem

Throw out your solution ideas; it’s not time for them. Solutions are the response to a problem, and the problem is more important. Building solutions before fully understanding the problem is like giving CPR to a person with a headache.

You have to do your best to define your problem at its root. You’re not looking for a Director of Marketing just because you don’t have one, you’re doing it because your product needs to reach more potential customers in order to grow. That improved definition of the problem will lead to more potential solutions, like paying for sponsored placements in app stores or changing the functionality to promote sharing. You don’t want to paint yourself into a corner with a problem statement that’s really a solution statement.

Research the Problem

Now that you’ve defined the problem, label that as a hypothesis or assumption and begin work to disprove it. Anything goes, here, but here are some common approaches:

  1. Talk to potential customers and try to have them describe their desires to you. See how well they match your hypothesis.

  2. Look for other businesses that are also solving for this problem. Do their solutions line up with your understanding of the problem? How successful are they? If they have an idea or help portal, read through the articles. Are customers happy with their solution, or does it seem like they’re missing a major point?

  3. Try to understand the size of the target market, is this a niche problem? What sort of demographic information can you find for the people experiencing the problem? What language(s) do they speak? How old are they?

  4. If you were thinking about that marketing hire, look at what other companies like yours are doing. Do the successful ones have a Director of Marketing? What does the turnover for the position seem to look like?

This phase can be more art than science. What’s important is that a real attempt is made with its goal being to uncover new information and better understand the accuracy of the hypothesis. If you disprove your hypothesis, that is a success! Replace it with a better one and repeat this step if needed. If your findings support your hypothesis, that’s good too, as long as you made the attempt to disprove it.

I was once about a week into an important UX debate with another Product Manager at Calendly. And we were attending a zoom-based team building exercise and the exact scheduling scenario that we were debating happened to us! We were able to talk about what our assumptions were vs the actual outcome and it helped us to better understand the problem. Research findings can come from anywhere, you just have to be open minded.

Solutioning

With your deep understanding of the root problem, it’s time to ideate on solutions. If your problem is understood at its root, then countless solutions can be imagined.

If you’re a Product Manager, this is a good place to involve a Designer and an Architect or Senior Engineer. Having all three domains ( Why, What, and How ) involved in the ideation can help at weeding out the good ideas from the bad ones.

Designers can sometimes be too creative or too clever. More senior designers should be able to balance this on their own but less experienced designers might come up with UI’s that elegantly solve the problem, but are difficult to understand by anyone outside of this meeting.

Engineers can have the opposite issue, and again, more seasoned Engineers will be less susceptible. Make sure the Engineer doesn’t say that things are impossible as a knee-jerk reaction to new ideas. Get them to explain to you why it’s impossible, and answer your follow up questions. Encourage creative solutions.

Prototyping

Now you have 1 - 3 potentially viable solutions. How can you find the best and quantify how good it is with minimal time and effort? This could easily be its own blog article but here are some of the classics:

  • Create mockups of the solution and show them to the customers that you talked to during your research phase. Have them describe how they’d interact with the UI being presented and what they would expect to happen as a result.

  • If there are technical challenges or risks, have the Engineer work on a Proof of Concept. This is minimal code to demonstrate that a solution will work in practice.

  • When possible, create an interactive Proof of Concept to show to people and gauge their reaction. Be sure to set the expectation that this is an experiment.

Does it solve for the problem without creating new ones? Is it much easier than the previous work-arounds? What is the excitement level from the potential customers?

MVP Solution

Now you’re ready to scope out your MVP (Minimum Viable Product). You want to think of this as an MVP because you’re still wondering what you missed! Getting the solution out into the real world in its simplest form will allow you to further measure how good it is. This means that you can pivot, roll back, or stop investing more into it based on what you see.

Be sure to define what success will look like and plan the work to track the metrics to determine that. This can’t be an afterthought, it’s usually part of the work.

Conclusion

If you’re thorough with this process and move carefully through these steps, I guarantee that you’ll toss out bad efforts before significant time and money is wasted on them. The good efforts will be executed extremely well and success will follow.

Previous
Previous

Making changes to database schemas

Next
Next

How difficult is it to change decisions?