Skip to main content

Product Lifecycle

How do we get from problem to solution?​

Before we develop a feature, we must understand its purpose. In other words, we must make sure our time is well spent solving the most important problems first. To make sure we understand problems and solutions, we go through a process called the Double Diamond framework.

Getting from understanding the problem to designing a solution requires a dual-divergance/convergance process called the Double Diamond.

Each Feature Request must undergo this process BEFORE we insert it into our roadmap. This is done to prevent overeager investment of time and effort in something that might not have optimal value to the end-goal of the platform.

Discover​

Discovery, the first phase of Double Diamond, is required whenever we must better explore the problem space. To explore problem spaces, we gather lots of data -- usage metrics, surveys, Q&A with users, behavioral observation, etc.

📘 Where is your feature request now?

We will be begin review of your request by "ripping the brief." In other words, we will begin by throwing out any assumptions and viewing your request through the lense of the problem you might be encountering (which your feature might solve).

We will start defining areas we want to look into, questions we want to ask people, and who to ask them of. We might call you, to better understand your request. If we can connect your request up to a known problem (or a problem space already undergoing research), we will!

Define​

Next, we define the problem by narrowing down our focus based, understanding the opportunity that will arise if the problem were to be solved. In case of multiple problems, we typically prioritize the ones that will grant the greatest value if solved (or prevent the greatest cost).

By the end of this step, we probably have a document with key insights from our discovery and definition research steps. Typically, we also have a problem defined, the first page of a Problem Solution Alignment Two-Pager.


📘 Where is your feature request now?

We have defined a problem, but we have not yet defined a solution for that problem! Your feature request, if it would solve that problem, may still be our end-solution IF (within the two steps following this one) it is the best solution to solve the problem.

You might see a two-pager coming to life with the problem defined on the first page.

Develop​

This next stage is where we dream up all the possible solutions that might solve the defined problem. All ideas are welcome in this step; there are no bad ideas. There are many ways to generate ideas, like:

  • Crazy Eights: The goal of this exercise is to create 8 rapid iterations of a possible solution for your problem.
  • Three step concept: when your idea needs to be as elaborated and detailed as possible.
  • Quick Ideas: great way to get unblocked and warm up to create more in-depth ideas. 
  • Four Panel Concept: a mass of ideas for experiments to solve organizational, business, or product challenges;
  • Scamper: is a great technique for creating crafting ideas for an existing product or service in a structured way.
  • Lightning Demos: find as many great examples of other companies solving a similar challenge as possible, and leverage their key aspect in solving your own challenge.
  • Round Robin: iterative technique that ensures that every voice in the room gets heard.

Evaluating these ideas can also be done in several ways:

  • Dot voting
  • Four Categories
  • Bingo Selection
  • Idea Affinity Diagram
  • Six Thinking Hats
  • Now Wow How Matrix


📘 Where is your feature request now?

If your feature request is a candidate solution for this problem, then we are considering it in this step and evaluating its efficacy.

We will be considering things like (but not limited to) buildout complexity and effort, cost, technical tools required, synergies with our existing features and other features in-flight, and other planned features on our roadmap.

Deliver​

Once we have produced and evaluated potential solutions, we pick one for implementation and execution. We may elect to build a prototype or do a spike first, before full buildout is initiated, just to make sure we have the right solution in mind.

Prototypes reduce misunderstandings and prevent unfulfilled expectations. Prototypes also provide the added benefit of being demo-able to users, who can then give feedback on utility.


📘 Where is your feature request now?

A two-pager has been fully written by now, both problem and solution defined. This two pager will detail the benefits of solving this problem, solution requirements, and a feature (or set of feature tickets) has been put into the product backlog.

If your feature request is (or is a part of) the solution, then your feature request is now in the roadmap.