• Darren Cody

Storytelling Solution Product Development

Updated: Aug 13

What Are Popular Product Development Methods?






Product Development is a complex process and has many different variations or adaptations from Startups to Enterprises. Asana, which is a popular Product Development tool to manage the project recently published a blog post on the proper Product Development Process. It is a simple, yet complex 6-Stage Process.

  1. Idea Generation: Brainstorming a product concept

  2. Product Definition: Scoping and refining the product concept

  3. Prototyping: Producing a wireframe

  4. Initial Design: Crafting a working prototype

  5. Validation & Testing: User & Stakeholder testing

  6. Commercialization: Shipping and implementing the product

This is the standard process that many companies will use and add their own "style" to it depending on the company's Product Culture & Business Requirements or Constraints. The PDP (Product Development Process) is meant to be collaborative and cross different teams in the Organization.


Pragmatic Institute is an esteemed entity in the Product world. They have created their own framework that they teach in stages of certificates. They created 7 Categories that each have unique activities from the Strategy to Execution spanning Market & Product requirements.


Strategy

  1. Market

  2. Focus

  3. Business

  4. Planning

  5. Programs

  6. Enablement

  7. Support

Execution


One potential issue with this effective Framework is that it takes time & resources that some Startups can't afford, only large Enterprises can. This leaves Startups being forced to make compromises on stages or steps of the Framework that need to be adjusted or even removed because of constraints. This can quickly lead to a cycle of only building features and becoming just another "Feature Factory" instead of helping solve your User's problems.


Just Another Feature Factory


This is mostly focused on the Startup Life because the majority of Startups do not have established processes in place, can afford to take weeks to define a solution, or have the effort resources to accomplish it effectively unlike an Enterprise.


Startups are constantly evolving at a neck-breaking speed or pivoting based on the needs of the market. Often, Product & Design teams are either very small or non-existent altogether as the Founder is holding these responsibilities. This of course is not every case, but from our experience, it is more than enough to mention.


Product & Design Teams at a Startup can be "bullied" by large Stakeholders (C Suite, or Investors) into defining, designing, and building the next "shiny" feature. The end result of this is the company's Product Culture is all about releasing Features and they've lost sight of the User who is paying for their product to solve a problem they have. Nobody wants to work or invest in a feature factory when you're in Startup mode. It creates a chaotic roadmap and constant shifts in priorities which results in wasted effort.



Our Experience, Strength, and Hope


The Product & Design Team at Marketplace Studio strongly believes in learning from our past, making required adjustments in a quick fashion, and validating a hypothesis before getting to market. Our team has worked on a variety of Startups, every time learning from the previous and looking for the most optimal route to success. The main reason why our Clients love us is because of our experience on past marketplaces and how we learn by performing internal Retrospectives on each one.


We implemented the Design Thinking Methodology to design and define our Features since day one because we encourage every Startup to iterate on a design first then later in the code. This saves effort & money. Design Thinking is a 5-Step Process to design and define a problem to come up with an effective solution.

  1. Empathize

  2. Define

  3. Ideate

  4. Prototype

  5. Test

We would have 3-person Design Thinking Sprint Teams to run through every Step of each workflow we created for a Platform. One Lead Designer and two Product Managers and typically the (Co)Founder. We found this extremely effective and helped ensure we understand what the Users need and how they want to interact with that workflow in the UI (User Interface).


Our Hybrid Process was actually 10-Steps:

  1. Define The Problem

  2. Emphasize With Users

  3. Market Inspiration & Understanding

  4. Collaborative Voting

  5. Prototype

  6. User Testing & Validation

  7. Prototype Refinement

  8. Copy & CTA Review

  9. Write User Stories

  10. Begin Development


This hybrid approach is an excellent way to ensure that you are building something that your Users want or even need, but it is slow and very design heavy. While Design & UX are of utmost importance, it is slow and does not always create the simplest or most effective outcome.


We would design some truly amazing prototypes and would gather spectacular feedback, but was it the correct feedback or the correct workflow in the first place?


Storytelling Solution Development


The main difference in this version of a PDP is Step 6, Define a Potential Solution in Words. This is because as Product Managers or UX Designers, we are supposed to be Story Tellers. We should be able to verbally "paint a picture" that articulates the problem, who has the problem, and the proposed solution. Having this Step before even creating a design (Wireframe or Prototype) will help maintain a level of simplicity in the solution you're going to build.


Performing User Testing by telling the Story allows you to quickly evolve the concept and flush out the major details but not get stuck in the weeds.


This process is because I was receiving feedback as a Product Manager who doesn't come from Engineering from my Senior Developer that I shouldn't spend so much effort trying to plan out the technical details of the Solution for the Developer. That is his job because he is simply better than I am in that domain. It was my responsibility to ensure I am effectively communicating the Solution (Context, Problem, Persona, Solution, and the Full Scope) to the team.


This is only the Pre-Development Process, it does not include any Product Marketing that is required for launching a Solution or Product.


  1. Describe the Primary Use Case for this Feature

  2. The purpose of this is to make sure everyone involved from the beginning to the end of this feature understands the "WHY" behind it and its intent of it. The outcome of this should result in the "Golden Path" of the feature. This should clearly outline the Pain Point / Problem in one or two sentences and a hypothesis for a solution.

  3. Describe Potential Edge Cases for this Feature (Minimum of 3)

  4. The purpose of this is to make sure we aren't thinking with our "Blinders" on. This will allow Product to clearly explain to the Lead Dev what potentially could happen and the Dev may suggest alternative solutions.

  5. Describe the Personas -> Primary, Secondary, Negative, and Buyer

  6. This will take a lot of effort and might not be doable right away. The idea is that Product & Marketing create real Persona Cards that the entire company will learn and memorize. This will allow us to brainstorm a lot better and focus on the problem we are solving. Click this to understand the purpose.

  7. Conduct Market Research -> How Large is this Problem?

  8. This is to understand if this problem we are attempting to solve is large enough for us to spend time & energy on. It will allow us to prioritize accordingly. Ideally, the results of this Step are aligned with our Product Strategy (Initiatives & Goals). The reason why this isn't the first or second Step is that we need to understand our first 3 to comprehend the scope of the problem before we can accurately analyze. Similar to the Empathy Step in Design Thinking

  9. Get Inspired

  10. We perform research on what solutions are currently on the Market to our problem. Not necessarily just with competition, it could be anywhere, digital or in real life. Ideally, we gather screenshots of that solution to vote on as a group what the best solution could incorporate.

  11. Define a Potential Solution in Words -> Storytelling

  12. Similar to creating a Low Fidelity Prototype, we can write a potential solution and we should be able to easily and concisely explain it verbally to anyone. The belief is that if we need a design to support our explanation, it is too complicated. We do internal testing if we are short on time. External if we can afford the extra effort.

  13. Iterate The Story

  14. By now, we have some feedback on our proposed solution. We need to incorporate the important bits of feedback that suit our Personas the best. Your Story should evolve as you receive feedback but remember to document adjustments and the WHY behind each tweak.

  15. Prototype

  16. Now it's time to draft a design in Figma or XD to support our solution. Ideally, you have a Design System in place and can skip wireframes.

  17. Validate

  18. Do internal & external testing and adjust as needed. Now it is time to combine the Storytelling with an asset, the design/mock/prototype. The questions asked in the Interview should be planned in advance and phrased in ways that prompt quality and unbiased responses.

  19. High-Fidelity Prototype

  20. All of the Components & Frames on every page are grouped and labeled accordingly. Every component should be following your Design System to allow the Product Team to write effective User Stories. This is nearly what the Developers will mirror.

  21. Copy Review

  22. Marketing reviews the copy now that we have a high-fidelity prototype to perform spell checks, messaging, CTAs, and the voice.

  23. Solution Review with Developer

  24. The Solution Team Lead reviews absolutely every detail from every Step above. The job here is to give as much context as possible to this Dev. The Dev should be able to provide an estimate for Story Points.

  25. Write User Stories

  26. The Product Manager is assigned the Solution to write the User Stories in Figma that link to a Jira ticket.

Solution Process Effort Timeline:


Please keep in mind that we originally would do a Design Thinking Sprint with 3 people which would span 5 days that resulted in a lightly tested high-fidelity prototype. Also, 3 to 5 days for writing the User Stories.


Day 1: Steps 1 to 3

Day 2: Steps 4 to 5

Day 3: Steps 6 to 7

Day 4: Steps 8

Day 5: Steps 9 to 10

Day 6: Steps 11 to 12

Day 7+: Step 13



If you're interested in discussing further or seeing what Marketplace Studio can do for your Startup, please connect with us.