Product Strategy Exercise | Company X Product Challenge

Note: This challenge was originally in the form of a deck, but is formatted here as a document.

completed July 2021

Activity #1: Evaluating a new product offering

Scenario: The largest sized art we frame today is 32” x 40”. Anything larger than that is considered “Oversized”. Company X customers regularly request to be able to frame pieces larger than we offer today, and we are forced to turn them away. We cannot simply add a larger size to our website and begin manufacturing oversized frames using our current materials (which are specifically built to support contents up to 32” x 40”) because the frames would not be structurally sound. In order to be successful, we will need to use different materials, assembly processes, and delivery methods to manufacture and deliver Oversized Frames. You’re tasked with evaluating what it would take to support this new offering.

  • Provide a high-level overview of how you would approach this project, including activities, key milestones and stakeholders you would include.
  • How would you size the opportunity?
  • What questions would you seek to answer at the onset, and how would you get answers to these questions?
  • What KPIs would you look at to measure the success of this project?
  • Provide a few examples of features (at an Epic level) that may go into an MVP? What would you build first vs. last and why? How would you measure success?
  • What are the key risks and challenges you would anticipate?

Overview

  1. What is the problem and is it real
  2. Why does Company X care
  3. Who are we solving this problem for
  4. How are we solving the problem
  5. How will we know the problem has been solved
  6. Identified tradeoffs to account for

This is the overview of the framework i followed when thinking about this problem. These questions led me to formulate an understanding of activities and milestones

Activities & Milestones

  1. Goal Definition resulting in Targeted discovery process
  2. Discovery resulting in Project scope definition
  3. Product Requirement Document resulting in Understanding ability to validate need before major changes
  4. KPI selection resulting in defined metrics that indicate success
  5. Product design resulting in MVP and plan for subsequent iterations pending usage metrics and qualitative insights

Discovery

  1. Define the issue "Company X’s manufacturing process has limitations that impact the product offerings that are available to the end user. This is costing Company X in lost revenue, users and perception as a market-leader in custom framing."
  2. Define stakeholders - who cares about this and why
    1. Business - lost revenue, marketshare
    2. Engineering - Development costs associated with any changes
    3. Manufacturing - Costs associated with manufacturing changes
    4. Retail - Change in allowable sizes impacts their intake process
    5. Consumer - Some amount of consumers that might otherwise use Company X aren’t. Our solution should seek to solve the originating pain point of desired dimensions being unavailable. Leverage internal knowledge to understand if the size limitation is crucial business issue
  3. Determine scope of problem
    1. What do I know, what can I deduce, what do I need to ask
    2. Purely monetization or are there marketing/growth incentives driving interest
    3. To size the opportunity, I’d look at the count of sessions where users select > 32” Width and or 41+” Height options from size dropdown menus and use the conversion rate for users that select allowable dimensions to get an understanding of the estimated loss in revenue. I’d also want to review consumer feedback and requests related to oversized frames to make sure our proposed solution fits.
  4. Product goals
    1. Increase revenue, grow marketshare, grow market understanding of what is frameable

Question triaging

Information I must have vs. should have Must: Current business impact, Manufacturing costs/downtime, Overarching goals alignment, Eng cost Should: Market conditions, Qualitative user research

Business stakeholders - Manufacturing - Engineering - Retail

I have a lot of questions! The high upfront costs associated with making this change means that we need to be overly diligent in our process to determine if and how we address these challenges. Also, the change would have wide-reaching implications across multiple teams and services that we need to be aware of. At the onset I want to schedule ~30 minute calls with representatives of each of the 4 defined internal stakeholder groups to gather a deeper understanding of the opportunity and challenges. Whenever possible, I like to send an outline to participants in advance of a meeting so that everyone’s clear on the conversational goal. Note: Some quantitative questions may be answerable without a scheduled meeting and some questions apply to more than one team.

Questions

I must know asap:

  1. The understood scope of this opportunity
  2. All limitations that have prohibited this product offering up to this point--What has kept FB from not doing this already?
  3. The costs associated with making this change (eng, manufacturing, retail)
  4. Reasoning behind the initial decision to not offer oversized frames, have the conditions changed?
  5. Is solving this challenge inline with Company X’s mission?

I should know:

  1. Are our competitors offering oversized frames? (looks like Michaels solution is limited to 40x40)
  2. Is there an upper limit on what an oversized frame’s dimensions may be?

I’m a big fan of Notion, I used it to help visualize questions and their association with different stakeholders and prioritization.

image

KPIs

From a high level we want to set KPIs that allow us to measure hypothesized impact as well as unintended impact on business operations.

  1. Are users purchasing oversized frames? Are they doing so at a cost to overall revenue? Maybe fewer purchases are made overall in favor of the oversized frames.
  2. Have our changes had an impact on the types of purchases users are making?
  3. Have our changes impacted the manufacturing team’s ability to process non-oversized frame orders?
  1. Revenue from orders that include 1+ oversized frame
  2. Revenue per order
  3. Revenue per user
  4. Orders per week
  5. Avg. Item count per order
  6. Time to deliver across all orders
  7. Time to deliver across orders w/oversized frame

Features

  1. Oversized Art Build view - The Oversized Art section will be similar to existing Build views. We should limit the dimension options to pairs (similar to Gallery Wall Size menu options).
  2. Add Oversized Art to Get Started gallery on main site - Should invest in the visibility of this new product offering to increase awareness rather than relying on the dropdown menu options for dimension to drive adoption.
  3. Add oversized frames to Gallery Wall collection - Offering gallery wall options that use oversized frames will help drive adoption. This will likely take some designer ideation and conceptualization, so I would first build the Oversized Art Build view to validate user interest.

Key Risks & Challenges

Facility downtime to prepare new manufacturing process

Manufacturing processes redesign including

  • Upfront material costs
  • Delivery method costs
  • Facility storage capacity for oversized frames Engineering time Designer time Shipping costs as prohibitive to consumer

Benefits

Acquisition of new customers

Increased engagement with existing customers

Increased revenue through new product offering

Payback period for manufacturing process change and upfront materials cost Go after a new product offering to increase market potential, greater range in product offering, greater likelihood of matching with customer needs and wants. Tradeoff: Requires major overhaul of existing manufacturing process, how costly is this and can the increased market potential the new product offering introduces account for that expenditure of resources and time. downtime of factory? upfront cost of different materials, delivery methods

Activity #2: Art intake tool at Company X

Scenario: You started working at Company X and were dropped in the middle of the design process for a new tool. Before manufacturing a frame, the artwork a customer shipped to the factory goes through an intake process. This is the tool used to assist in that process. The goal of the tool is to get the art ready to enter the manufacturing process (actually building the frame around the art), and handling any exceptions. Below are wireframes you’ve been handed for a few key screens of this tool.

  • Explain what key challenges you think the tool is meant to solve.
  • How would you assess whether the designs you’ve been handed address these challenges?
  • Break down the tool into key features. What would you work on first? What would you work on last?
  • How would you release an MVP?
  • What additional features might you consider adding?

Key Challenges tool seeks to address

  1. Lost shipments - Receiving shipment and verifying expected items within
  2. Damaged Items - Documenting item condition upon receipt
  3. Item incompatible with frame/matting selected by user - Editing frame spec if item not compatible with mating and frame chosen by customer
  4. Misplacing items once within the manufacturing process - Logging items into manufacturing system with an RFID
  5. Work order doesn’t match contents of shipment received - Dimensions, material, quantity of items
  6. Edge cases in item-handling requirements
  7. White glove required, certificate of authenticity included requirements

Product Goals

  1. Accuracy - Allow user to input accurate information that is used throughout the manufacturing process. Allowing consumer to receive the product they expect
  2. Speed - Intake process should be efficient, consumers expect a relatively quick turnaround time from FB
  3. Issue-surfacing - Order-item misalignment, damaged item, special-instructions required, etc.
  4. Ease-of-use - Tool should load quickly and have minimal latency, allowing user to focus on the shipment and items
  5. Consistent experience - We want to instill familiarity with this tool, allowing the manufacturing team to scale in efficiency as their comfort level increases

User Persona

Who are the users of this tool?

Manufacturing Team employee

  1. Not necessarily digitally native
  2. Operating within a loud environment
  3. Going back and forth from the shipment/item to the intake tool
  4. Experience in manufacturing, not digital tools
  5. As familiarity with tool increases, comfort does as well, thus resistant to arbitrary change
  • Likely to interpret tool functionality/instructions differently than product team would assume (Product team should not assume when ideating or designing)
  • Intuitive interface with clear functionality more valuable than slick feel
  • Are they using a mobile device or a desktop? Their eyes and hands are bouncing back and forth between physical items and application, should think about the tool with that context in mind.
  • User is not enthused by learning new processes on a regular basis, any changes to functionality should be made with a large confidence in viability of new solution. Bringing the manufacturing team into the process on some level may assist here

Are the challenges addressed?

  • Functional Requirements in PRD - I’d look to the Functional requirements contained within the PRD to cross-reference against these wireframes in order to determine if known challenges are addressed
  • Qualitative and quantitative information available - I’d also like to know if we have any qualitative or quantitative information that was used to inform the choices demonstrated in these wireframes (field location and prominence, toggles, checkboxes, dropdowns, text fields)
  • Similar tools as point of comparison - Does the manufacturing team currently use tools that we can compare our choices against for a consistent cross functional experience?

In an absence of quantitative metrics:

  • Seek early feedback via sharing mocks with stakeholders
  • Share mocks with subset of users, watch them navigate main use flows

Sharing mocks with stakeholders, a subset of users, etc. can help validate early concepts without much cost associated. This is especially important if your designs lack qualitative or quantitative data support. Some loose user testing can help inform our decisions as we go from wireframes to mockups.

Key Features

  1. Item intake
  2. Condition documenting
  3. Frame Spec management

Measuring Success or Failure

  1. Average Time to intake on a per-user basis | Avg. Time to intake - Measurement of time from when user clicks Receive shipment button to when they click Scan Next Package (should be grouped by # of items per shipment)
  2. Error Rate - % of instances when changes made to Frame Spec, or other work order fields AFTER item has been received by intake specialist would want to see this as a percentage of total item intake volume
  3. Abort Rate - Hard to measure dropoff rate when a form is required, but the abort button should provide some insight. Do all views have the abort button and are we able to measure the step from which the user clicked?

These can provide some insight into broad trends, but qualitative analysis is very important here, especially as the project gets off the ground. There’s a lot we know that we don’t know.

MVP

Key Features

  1. Frame Spec Management
  2. Logging RFID
  3. Shipment & Item Receiving
  4. Condition documenting

Challenge with releasing MVP of internal tooling -

Threshold for internal tooling MVP would seem to be considerably high. Without a functional intake tool that covers all of the main use case, the manufacturing team is left switching back and forth between the new tool and old processes in order to cover all areas of need. Is this inefficiency worth the desire to release a tool that requires immediate high-stakes iteration? Are we able to release a tool that is somewhat incomplete without interfering with existing levels of productivity? How tolerant are we of short-term impacts in that area?

Assuming we have existing processes in place for the main use case and all edge cases I would focus on releasing functionality in three separate epics:

  1. Frame Spec Management
  2. Condition documenting
  3. Shipment & Item Receiving (includes RFID)

I’m pretty torn on this one and I think i need more information before I can feel comfortable making a call. Given that we:

  1. Have minimal quantitative and qualitative analysis to reference
  2. Have no other internal tools that we can reference and mimic in style and functionality

We may be basing a lot of our decisions on workflow choices on misaligned understandings. I see this as a smaller risk if we focus our initial efforts on a lower-risk workflow area where we can use our learnings to apply to the more complex components of the process.

Items shipped to Company X’s facility are one of a kind and invaluable to the consumer. Any item damaged while in our care is a huge breach of consumer-trust, and if documenting an item’s condition has shown to help prevent that, we should prioritize it. But before we can focus on that segment of the intake funnel, we first should confirm shipment and item receipt. Without confirmation that a shipment and its contained items are in our possession, we aren’t able to verify their condition.

I think we will see the most juice to squeeze relationship in terms of development costs, manufacturing team adoption and increased process efficiency through the Shipment & Item Receiving functionality.

Initial Efforts Shipment & Item Receiving Functionality

Main User Flow:

  1. Scan Package
  2. View Line Items in Order, dimensions, package and order ID
  3. User selects an item and clicks Begin Receiving
  4. User provides description and image of item, clicks Item Received button
  5. User is viewing Capture RFID view user clicks Next
  6. User clicks Receive Next Item OR user clicks Item Intake Complete button

Functionality to be layered in

  1. Condition Documenting - Important to the success of process, not as important as the spec itself
  2. Frame Spec Management - Crucial workflow function. Will build using learnings from initial release
  3. Automated Onboarding - How frequently are new Manufacturing Team members joining Company X?

Short term - emphasize main usecase flow required in Shipment and Item Receiving including RFID functionality. If we misplace the item the efficiency of the process is moot

A significant benefit of starting with this smaller, more manageable usecase is we should be able to release something that accomplishes these tasks quickly—giving us the opportunity to conduct the user research we need to gain insight into pain points.

edge case functionality should be available if necessary but not assumed to be part of every intake

Long term - engage in a thorough discovery process that seeks to deeply understand user pain points experienced during the intake process Automated Onboarding as a worthwhile addition will depend on analysis of the frequency of new manufacturing team members and the cost in hours to manually train how to use intake tool