--- title: Solutions description: Truefit partners with established organizations to build, accelerate and modernize software with Idea Launch™, our AI-enabled delivery framework. image: https://truefit.io/hubfs/SOLUTIONS-feature-truefit-idea-launch-innovation-framework.webp --- [Skip to content](https://truefit.io/solutions#main-content) [![truefit](https://truefit.io/hubfs/Truefit.svg) ![Truefit](https://truefit.io/hubfs/truefit-logo-new.svg)](https://truefit.io/?hsLang=en) - [Work](https://truefit.io/our-work) - [Solutions](https://truefit.io/solutions) - [About](https://truefit.io/about) - [Insights](https://truefit.io/insights) Open main navigation Close main navigation - [Work](https://truefit.io/our-work) - [Solutions](https://truefit.io/solutions) - [About](https://truefit.io/about) - [Insights](https://truefit.io/insights) - Idea Launch™ is a proven process for discovering and building successful products. [Let's Talk Software](https://truefit.io/contact) ©Truefit. All rights reserved [Let's Talk Software](https://truefit.io/contact?hsLang=en) # Build what matters. Deliver what’s critical. Innovate what’s next. Whether you’re building a new software product, accelerating a mission-critical initiative, or innovating with AI across your roadmap, we bring senior-led, disciplined execution that delivers market-ready solutions that scale. ![Three diverse professionals representing a collaborative team, layered over a vibrant, abstract background of motion-blurred lights, symbolizing Truefit's human-centered approach to software innovation.](https://truefit.io/hubfs/Approach_hero_2.webp "Three diverse professionals representing a collaborative team, layered over a vibrant, abstract background of motion-blurred lights, symbolizing Truefit's human-centered approach to software innovation.") --- ### When timelines tighten, complexity increases, or innovation carries real business risk, we provide the structure, velocity, and accountability to move forward with confidence. --- ## Idea Launch™: A proven framework for delivering software with confidence Idea Launch is Truefit’s well tested, AI-enabled approach for turning complex initiatives into production-ready outcomes — faster, with less uncertainty. We can adapt each phase of Idea Launch to meet your unique needs and business context—whether you’re focused on building new or modernizing existing software, accelerating delivery, or innovating what’s next. #### Five critical components that determine product success ###### Define KEY QUESTION **Are we solving the right problem—and why does it matter now?** ###### Demo KEY QUESTION **Will this create real value for customers and the business?** ###### Develop KEY QUESTION **What is the smartest path to delivering value?** ###### Deliver KEY QUESTION **How do we deliver reliable software that achieves the intended outcomes?** ###### Drive KEY QUESTION **How do we scale impact and keep improving over time?** ![hammer_white](https://truefit.io/hubfs/hammer_white.svg) #### Build with Idea Launch™ Hover over each component to explore ![Check-list icon](https://truefit.io/hubfs/list-checks.svg) ![Target icon](https://truefit.io/hubfs/target.svg) ![pencil-ruler-white](https://truefit.io/hubfs/pencil-ruler-white.svg) ![Rocket icon](https://truefit.io/hubfs/rocket.svg) ![Map icon](https://truefit.io/hubfs/map.svg) ##### From product gap to scalable impact. When you need to build or modernize a mission-critical product, Idea Launch™ drives from validated concept to production-ready software — on scope, on schedule, with architecture built to scale. ![gauge_white icon](https://truefit.io/hubfs/gauge_white.svg) #### Accelerate with Idea Launch™ Hover over each component to explore ![list-checks icon](https://truefit.io/hubfs/list-checks.svg) ![target icon](https://truefit.io/hubfs/target.svg) ![pencil-ruler-white icon](https://truefit.io/hubfs/pencil-ruler-white.svg) ![rocket icon](https://truefit.io/hubfs/rocket.svg) ![map](https://truefit.io/hubfs/map.svg) ##### From proven product to predictable scale. You’ve validated the vision. Now the work is execution — shipping faster, hitting roadmap targets, and scaling what’s working. Idea Launch™ steps in to accelerate feature delivery and sustain the momentum you’ve built. ![wand-sparkles-white](https://truefit.io/hubfs/wand-sparkles-white.svg) #### Innovate with Idea Launch™ Hover over each component to explore ![list-checks](https://truefit.io/hubfs/list-checks.svg) ![target](https://truefit.io/hubfs/target.svg) ![pencil-ruler-white icon](https://truefit.io/hubfs/pencil-ruler-white.svg) ![rocket](https://truefit.io/hubfs/rocket.svg) ![map](https://truefit.io/hubfs/map.svg) ##### From emerging opportunity to validated direction. When the opportunity is real but the path isn’t clear, we adapt Idea Launch to front-load strategy and technical exploration — turning high-potential ideas into evidence-backed solutions ready to scale. ## Decoded: The thinking behind every Idea Launch™ Conversations from inside about what actually happens between idea and launch. ### Introducing Decoded: Create Better Software Products ![arrow](https://truefit.io/hs-fs/hubfs/insights-arrow.png?width=40&height=40&name=insights-arrow.png) For 25 years, Truefit has helped business leaders build software that solves a real problem. Decoded breaks down how. ✕ ## Video Summary & Key Insights Title Topic: Introducing Decoded: Create Better Software Products Description: For 25 years, Truefit has helped business leaders build software that solves a real problem. Decoded breaks down how. Shorts Full Episodes ALL TOPICS PRODUCT STRATEGY DEFINITION RISK & VALIDATION MARKET FIT & VALUE TESTING & EVIDENCE TEAM & PROCESS USER FEEDBACK & ENGAGEMENT ### Product Strategy Definition 7 Shorts Finding the right problem before building the solution. ![Identifying Key Problems preview](https://img.youtube.com/vi/PsIhGXayaRM/hqdefault.jpg) 01 SHORTS SHORTS #### Identifying Key Problems Most failed software launches aren't a technology problem — they're a problem of building something nobody needed. This short breaks down how to trace user symp... ▶ Watch ![We've Gone Through Discovery, What's Next? preview](https://img.youtube.com/vi/N7Sh1tP9rSw/hqdefault.jpg) 02 SHORTS SHORTS #### We've Gone Through Discovery, What's Next? Discovery only has value if it turns into a plan a team can execute. This short covers the handoff from discovery insight to a prioritized, buildable backlog. ▶ Watch ![Where Good Ideas Come From in Product Development preview](https://img.youtube.com/vi/wyIkXG60Wfs/hqdefault.jpg) 03 SHORTS SHORTS #### Where Good Ideas Come From in Product Development The best product ideas rarely come from one department. This short covers how Truefit builds space for engineers, designers, and customer-facing teams to surfac... ▶ Watch ![How Knowing Your Competition Helps Product Development preview](https://img.youtube.com/vi/cGnHG-WNwdM/hqdefault.jpg) 04 SHORTS SHORTS #### How Knowing Your Competition Helps Product Development Competitive research isn't about copying features — it's about finding the gaps competitors haven't filled. This short covers how a feature-gap analysis sharpen... ▶ Watch ![Getting to Know Your Customer During Product Development preview](https://img.youtube.com/vi/vNUoZktGE6M/hqdefault.jpg) 05 SHORTS SHORTS #### Getting to Know Your Customer During Product Development Strong UX starts with real customer understanding, not assumptions. This short covers how behavioral personas turn cold requirements into an interface that feel... ▶ Watch ![End User vs. Buyer in Product Development preview](https://img.youtube.com/vi/VPV9G1gH2VE/hqdefault.jpg) 06 SHORTS SHORTS #### End User vs. Buyer in Product Development In B2B software, the person buying and the person using the product are rarely the same. This short covers how to balance what a buyer needs against what a dail... ▶ Watch ![Do You Know What Your User's Goals Are? preview](https://img.youtube.com/vi/ckwrkiwsy_4/hqdefault.jpg) 07 SHORTS SHORTS #### Do You Know What Your User's Goals Are? Users don't buy features — they buy a better outcome for themselves. This short covers how a Jobs-to-be-Done framework clarifies exactly what a product needs to... ▶ Watch ### Risk & Validation 5 Shorts Making software initiatives predictable and shipping with certainty. ![Prioritizing Risk preview](https://img.youtube.com/vi/Vn0J2qTpsNE/hqdefault.jpg) 01 SHORTS SHORTS #### Prioritizing Risk Not every risk in a product launch carries the same weight. This short shows how to classify technical, market, and operational risk so the highest-exposure one... ▶ Watch ![Gathering Evidence Through Validation preview](https://img.youtube.com/vi/qzfR9yF6zeU/hqdefault.jpg) 02 SHORTS SHORTS #### Gathering Evidence Through Validation Product decisions hold up better on evidence than instinct. This short covers building a feedback loop that proves a concept is viable before a team scales arou... ▶ Watch ![Managing Risk in Product Development preview](https://img.youtube.com/vi/1plGRwOT-Rc/hqdefault.jpg) 03 SHORTS SHORTS #### Managing Risk in Product Development Managing risk isn't about avoiding it — it's about building safe ways to test it. This short covers how small, agile sprints let teams try uncertain features wi... ▶ Watch ![Understanding the Risks in Product Development preview](https://img.youtube.com/vi/JRfO9CxDxLQ/hqdefault.jpg) 04 SHORTS SHORTS #### Understanding the Risks in Product Development Launching into a competitive market carries real stakes. This short summarizes the structural checks that keep a product launch on solid ground. ▶ Watch ![Understanding the Risks of New Product Development preview](https://img.youtube.com/vi/-nBEc3INIXM/hqdefault.jpg) 05 SHORTS SHORTS #### Understanding the Risks of New Product Development This short wraps the series by recapping why a disciplined approach to risk is a real competitive advantage in software. Truefit's leadership closes out the fra... ▶ Watch ### Market Fit & Value 7 Shorts Compressing time-to-value to turn ideas into scalable working software. ![Understanding Product Market Fit preview](https://img.youtube.com/vi/s0WjnSzgqS8/hqdefault.jpg) 01 SHORTS SHORTS #### Understanding Product Market Fit Product-market fit isn't a fixed destination — it's a set of signals that shift over time. This short covers the leading indicators that show a product is solvi... ▶ Watch ![Finding Features to Reach Market Fit preview](https://img.youtube.com/vi/vYjYpEnFDdw/hqdefault.jpg) 02 SHORTS SHORTS #### Finding Features to Reach Market Fit Feature creep is the fastest way to miss a market window. This short covers how to narrow a feature set down to what an MVP actually needs. ▶ Watch ![Patience Is Key to Product Development preview](https://img.youtube.com/vi/FHq2l_-W8Zc/hqdefault.jpg) 03 SHORTS SHORTS #### Patience Is Key to Product Development Rushing into code to hit a deadline usually creates technical debt down the line. This short covers why time spent in strategic design pays off in development s... ▶ Watch ![How Product Design Is Like Playing Pool preview](https://img.youtube.com/vi/eOVR9wHlsNc/hqdefault.jpg) 04 SHORTS SHORTS #### How Product Design Is Like Playing Pool In pool, the next shot is set up three moves in advance. This short uses that idea to explain why product strategy has to account for scalability and market shi... ▶ Watch ![Is the Product You're Developing Solving the Right Problem? preview](https://img.youtube.com/vi/Fhs3VUOvyHM/hqdefault.jpg) 05 SHORTS SHORTS #### Is the Product You're Developing Solving the Right Problem? Founders need a clear answer to one question before scaling: is this solving a high-priority problem, or a minor one? This short covers how to test for the diff... ▶ Watch ![Is Your Product Valuable to Users? preview](https://img.youtube.com/vi/AtcfFcpB2Ks/hqdefault.jpg) 06 SHORTS SHORTS #### Is Your Product Valuable to Users? Value is defined by the user, not the product team. This short covers how to track perceived value against actual usage so a product stays worth using. ▶ Watch ![Do Your Customers Want This? preview](https://img.youtube.com/vi/BwN4Uu6c40w/hqdefault.jpg) 07 SHORTS SHORTS #### Do Your Customers Want This? This is the question every product decision comes back to. This short covers how smoke tests and landing page experiments answer it before a team writes product... ▶ Watch ### Testing & Evidence 1 Short Validating key assumptions continuously using data-led pattern proof. ![What Can We Learn From Early User Testing? preview](https://img.youtube.com/vi/Owk54emLX_g/hqdefault.jpg) 01 SHORTS SHORTS #### What Can We Learn From Early User Testing? Waiting until launch to gather feedback is too late. This short shows how testing low-fidelity prototypes early exposes friction points before they reach produc... ▶ Watch ### Team & Process 4 Shorts Senior-led cross-functional teams accelerating execution momentum. ![Product Development is a Team Sport preview](https://img.youtube.com/vi/4Qh9g57Jsh0/hqdefault.jpg) 01 SHORTS SHORTS #### Product Development is a Team Sport Software fails in the gaps between departments. This short covers how Truefit keeps design, business strategy, and engineering working from the same goal. ▶ Watch ![What Product Development Learns from Creative Work preview](https://img.youtube.com/vi/gL3Mg9QBiig/hqdefault.jpg) 02 SHORTS SHORTS #### What Product Development Learns from Creative Work Software development is a creative problem-solving process, not just a technical one. This short covers what borrowing from design frameworks brings to rigid te... ▶ Watch ![What Success Looks Like in Product Development preview](https://img.youtube.com/vi/rrHxgvSSkqQ/hqdefault.jpg) 03 SHORTS SHORTS #### What Success Looks Like in Product Development Shipping on time isn't the same as succeeding. This short covers the business outcomes — activation, retention, time-to-value — that define real product success... ▶ Watch ![Seeing Blindspots in Product Development preview](https://img.youtube.com/vi/Zp8-2jmnDJE/hqdefault.jpg) 04 SHORTS SHORTS #### Seeing Blindspots in Product Development Every product team carries internal bias. This short covers the review practices Truefit uses to catch product flaws before they become expensive after launch. ▶ Watch ### User Feedback & Engagement 6 Shorts Ensuring software and AI serve real people to advance delivery outcomes. ![How Interviews Help Product Development preview](https://img.youtube.com/vi/2wniND7rguw/hqdefault.jpg) 01 SHORTS SHORTS #### How Interviews Help Product Development Usage data shows what customers do; interviews show why. This short covers how to ask open-ended questions that surface the real reasons behind a buying decisio... ▶ Watch ![Why User Feedback Is Critical to Product Success preview](https://img.youtube.com/vi/oIXl6U2W0Uc/hqdefault.jpg) 02 SHORTS SHORTS #### Why User Feedback Is Critical to Product Success Software falls behind the moment there's no system for acting on user feedback. This short covers how to filter and weigh feedback so it actually shapes the nex... ▶ Watch ![User Feedback Is Critical To Success preview](https://img.youtube.com/vi/Rqy1WRg4Pvc/hqdefault.jpg) 03 SHORTS SHORTS #### User Feedback Is Critical To Success Not all feedback deserves equal weight. This short covers how to separate minor requests from the changes that actually move retention and engagement. ▶ Watch ![Turning User Feedback into a Product Roadmap preview](https://img.youtube.com/vi/hALwLC6YF_U/hqdefault.jpg) 04 SHORTS SHORTS #### Turning User Feedback into a Product Roadmap Feedback only helps if a team can separate the signal from the noise. This short covers how to sort feature requests into a roadmap based on what actually drive... ▶ Watch ![How to Connect With Users preview](https://img.youtube.com/vi/e_Pu9lAxnE8/hqdefault.jpg) 05 SHORTS SHORTS #### How to Connect With Users Great software closes the gap between engineering and the people using it. This short covers practical ways product teams stay connected to their audience. ▶ Watch ![How to Connect With and Engage Users preview](https://img.youtube.com/vi/UWvz8ARtzjM/hqdefault.jpg) 06 SHORTS SHORTS #### How to Connect With and Engage Users User engagement is built, not accidental. This short covers the onboarding patterns that turn a first-time user into an active one. ▶ Watch ![The Risks of New Product Development preview](https://img.youtube.com/vi/e_Bx9DWVeAI/maxresdefault.jpg) 01 35:00 Full Episodes #### The Risks of New Product Development In this debut Decoded episode, Truefit Founder Darrin Grove and Director of Product Design John Beck unpack the critical areas of product risk. They explore str... ▶ Watch ![What is Product Discovery? preview](https://img.youtube.com/vi/Ln-uQFq5-9g/maxresdefault.jpg) 02 37:27 Full Episodes #### What is Product Discovery? Darrin Grove and John Beck break down the three phases of product discovery — the essential early work that determines which problems are worth solving and whic... ▶ Watch ![Define Your Product Vision preview](https://img.youtube.com/vi/eCg5rPqSJQ8/maxresdefault.jpg) 03 27:29 Full Episodes #### Define Your Product Vision In this Decoded episode, Darrin Grove and John Beck focus on the Opportunity Space — the first phase of discovery, where user and market insights get synthesize... ▶ Watch ![Prototype to Test and Learn preview](https://img.youtube.com/vi/ChxWbqFkqhA/maxresdefault.jpg) 04 27:29 Full Episodes #### Prototype to Test and Learn Darrin Grove and John Beck walk through the Solution Space — the second phase of discovery, where teams turn a validated problem into a concrete, testable solut... ▶ Watch ![Chart Your Path to Market with Confidence preview](https://img.youtube.com/vi/3-0raNUbMag/maxresdefault.jpg) 05 24:42 Full Episodes #### Chart Your Path to Market with Confidence In this Decoded episode, Darrin Grove and John Beck cover the Alignment Space — the third phase of discovery, where prototyped solutions get validated with real... ▶ Watch ![Build Your Product and Continue Learning preview](https://img.youtube.com/vi/vRUjrEecwH0/maxresdefault.jpg) 06 25:53 Full Episodes #### Build Your Product and Continue Learning Darrin Grove and COO Dominick DeStasio open up the build stage of product development, covering the cross-functional skills a team needs and how agile developme... ▶ Watch × ![testimonial-icon](https://truefit.io/hs-fs/hubfs/testimonial-icon.png?width=182&height=221&name=testimonial-icon.png) > The software that Truefit built for us has been reliable and has completely transformed the way our team works and has allowed us to scale far beyond what I previously thought possible. Truefit is excellent at communication and explaining complex processes to non-technical CEOs like myself. They are able to understand our unique needs and talk us through potential solutions, while always being receptive to feedback our team provides. — Lillian Rafson, CEO ### Let’s start a conversation about your next software product launch. [let’s talk software](https://truefit.io/contact?hsLang=en) [![Truefit_Logo_White_RGB_2023aligned 1](https://truefit.io/hubfs/Truefit_Logo_White_RGB_2023aligned%201.svg "Truefit_Logo_White_RGB_2023aligned 1")](https://truefit.io/?hsLang=en) Truefit works with business leaders who need to create new and next-gen software products to explore new market opportunities, solve important problems, and grow their business. ![Phone Number](https://truefit.io/hubfs/smartphone.svg) [(412) 325-5959](tel:+14123255959) [![Follow us on LinkedIn](https://truefit.io/hubfs/LinkedIn_Logo.svg)](https://www.linkedin.com/company/truefit/) [![Follow us on YouTube](https://truefit.io/hubfs/YouTube_Logo.svg)](https://www.youtube.com/@TruefitPittsburgh) [![Follow us on Instagram](https://truefit.io/hubfs/Instagram_Logo_sm.png)](https://www.instagram.com/truefitpgh/) [![Follow us on Facebook](https://truefit.io/hubfs/Facebook_Logo.svg)](https://www.facebook.com/TruefitPgh/) Site - [Work](https://truefit.io/our-work) - [Solutions](https://truefit.io/solutions) - [About](https://truefit.io/about) - [Insights](https://truefit.io/insights) Location Pittsburgh, PA 1001 Liberty Avenue 5th Floor Pittsburgh, PA 15222 © Truefit. All Rights Reserved.[Privacy Policy](https://truefit.io/privacy?hsLang=en) ```json { "@context" : "https://schema.org", "@id" : "https://truefit.io/#organization", "@type" : [ "LocalBusiness", "Organization" ], "address" : { "@type" : "PostalAddress", "addressCountry" : "US", "addressLocality" : "Pittsburgh", "addressRegion" : "PA", "postalCode" : "15222", "streetAddress" : "1001 Liberty Avenue, 5th Floor" }, "areaServed" : "US", "description" : "Truefit partners with business leaders at established organizations to turn product strategy into working software, making software and AI initiatives predictable.", "disambiguatingDescription" : "Truefit is a US-based product development and software delivery firm that turns product strategy into working software. Truefit is NOT an apparel sizing, clothing tech, or e-commerce body measurement company.", "foundingDate" : "1997", "geo" : { "@type" : "GeoCoordinates", "latitude" : 40.4396217, "longitude" : -79.989505693828 }, "image" : "https://truefit.io/hubfs/Truefit.svg", "knowsAbout" : [ "Custom Software Development", "Software Product Development", "Legacy System Modernization", "AI Software Integration", "AI Task Force", "Product Design and UX", "Mobile Application Development", "SaaS Engineering", "Project Rescue and Acceleration", "Cloud-Native Application Development", "CTO Advisory", "Agile Product Delivery", "Healthcare Software Development", "Financial Services Software", "Manufacturing Technology Solutions", "AI Modernization", "Software Delivery Predictability", { "@type" : "Thing", "name" : "Product Strategy", "sameAs" : "https://en.wikipedia.org/wiki/Product_strategy" }, { "@type" : "Thing", "description" : "Truefit's proprietary, AI-enabled methodology for making software and AI initiatives predictable, structured around five components: Define, Demo, Develop, Deliver and Drive.", "name" : "Idea Launch Methodology" } ], "legalName" : "Truefit", "makesOffer" : [ { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Upstream discovery and AI Task Force exploration.", "name" : "Innovate" } }, { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Net-new product development from strategy to working software.", "name" : "Build" } }, { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Senior-led embedded teams to extend roadmap velocity.", "name" : "Accelerate" } }, { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Redesigning and re-platforming legacy enterprise platforms.", "name" : "Modernize" } } ], "name" : "Truefit", "openingHoursSpecification" : { "@type" : "OpeningHoursSpecification", "closes" : "17:00", "dayOfWeek" : [ "Monday", "Tuesday", "Wednesday", "Thursday", "Friday" ], "opens" : "09:00" }, "sameAs" : [ "https://www.facebook.com/TruefitPgh/", "https://www.instagram.com/truefitpgh/", "https://www.youtube.com/@TruefitPittsburgh", "https://www.linkedin.com/company/truefit/" ], "telephone" : "(412) 325-5959", "url" : "https://truefit.io/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://truefit.io/solutions#software-development", "@type" : "Service", "areaServed" : { "@type" : "Country", "name" : "US" }, "audience" : { "@type" : "Audience", "audienceType" : "Business leaders, CPOs, CTOs, and VPs of Product at established organizations" }, "description" : "Truefit partners with established organizations to innovate, build, accelerate, and modernize software products — with senior-led teams and AI-enabled delivery that make every initiative predictable.", "hasOfferCatalog" : [ { "@type" : "OfferCatalog", "itemListElement" : [ { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Run upstream discovery, validate assumptions, and define what to build and why. Can run standalone or in parallel alongside Build or Accelerate.", "name" : "Innovate" } }, { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Design and build a new product from concept to market-ready. Validate assumptions fast, reduce existential risk, and ship.", "name" : "Build" } }, { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Embed senior-led teams to extend the client's own team, maintaining and growing roadmap momentum without sacrificing quality.", "name" : "Accelerate" } }, { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Redesign, re-platform, or restructure existing products with minimal disruption to users and operations.", "name" : "Modernize" } } ], "name" : "Truefit Service Plays" }, { "@type" : "OfferCatalog", "itemListElement" : [ { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Align on business goals, user needs, competitive context, and technical landscape. Build the initial roadmap.", "name" : "Define" } }, { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Build the simplest artifact that tests the most critical assumption. Validate before you invest in full development.", "name" : "Demo" } }, { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Iterate toward production quality in small, testable increments. Release incrementally for validation.", "name" : "Develop" } }, { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Coordinate with partners and release to a public or private market. Measure impact.", "name" : "Deliver" } }, { "@type" : "Offer", "itemOffered" : { "@type" : "Service", "description" : "Continuously improve through iterative releases, ongoing prioritization, and measurement.", "name" : "Drive" } } ], "name" : "Idea Launch™ Framework" } ], "provider" : { "@id" : "https://truefit.io/#organization", "@type" : "Organization" }, "serviceType" : "Software and AI Product Development" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "For 25 years, Truefit has helped business leaders build software that solves a real problem. Decoded breaks down how.", "embedUrl" : "https://www.youtube.com/embed/X_YwAqMrnvY", "name" : "Introducing Decoded: Create Better Software Products", "thumbnailUrl" : "https://img.youtube.com/vi/X_YwAqMrnvY/maxresdefault.jpg", "transcript" : "It's a really exciting day here at Truefit — right behind me, we're setting up to film a new video series that's all about how to create amazing software products. My name is Darrin Grove, I'm the founder of Truefit, and for the past 25 years we've been working with people to create software products that have an impact on the world, that make people's lives better. We want to take you behind the scenes to explore the process we use to create new software products — a process we call Idea Launch. We're going to start with the discovery stage. We're going to look at the risks associated with creating a new product. We're going to look at product strategy and defining the problems. We're going to move to the solutions and prototyping. We're going to talk about how to get your whole team aligned throughout the process. And when you're done, you'll have the confidence you need that you're building the right product — that when you build that product, you're going to achieve product-market fit, that it's going to be successful in the market you're going after, and ultimately that's going to lead to business growth and help you achieve your business goals. So we're going to kick off this series talking about risk and success. We hope you can join us for that first episode — we'll see you there.", "uploadDate" : "2023-01-10T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Truefit's Darrin Grove and John Beck open the Decoded series by breaking down the risks every new product faces before a line of code is written.", "duration" : "PT35M", "embedUrl" : "https://www.youtube.com/embed/e_Bx9DWVeAI", "name" : "The Risks of New Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/e_Bx9DWVeAI/maxresdefault.jpg", "transcript" : "Welcome to this first episode in our Idea Launch series, which is focused on helping you create better software products. My name is Darrin Grove, I'm the founder of Truefit. My background is software development. Joining me today is John Beck — John is Truefit's Director of Product Design. Welcome, John.\n\nGreat to be here.\n\nI think in this first episode, where we'd like to start is maybe not a topic people think about a lot. Usually when we're working with somebody, we work with a lot of business leaders — they have an idea, they see an important problem that needs to be solved, they say, \"I think software can help,\" but they may or may not have a software team, they may or may not have ever built a product before. We work with a lot of people like that. They have deep domain expertise, and they're applying that to a solution — they see an opportunity. One of the things they don't necessarily think a lot about is the risks. But the reality is, when you're at the beginning of the product development process, you're at the point of maximum risk, because there are so many things you don't know. There are a lot of things you do know, but there are so many things you don't know. So what we'd like to do today is unpack some of these areas of risk that we're paying attention to really early on. Why don't you talk a little bit about those?\n\nOur teams have spent a lot of time over the years helping to widen our clients' understanding of risk. Naturally, they're concerned about money and time, but there are other important areas to look at. When we talk about risk, one of the first big ones we look at is a question of value: does your customer — or customers, on a more complex product — do they want this product? In other words, do you understand — a lot of times clients come to us with an understanding of a feature list, \"we need an app that can do X, Y, and Z\" — but how well do you really understand what the end goal, the end outcome, that your customer or user is seeking? We have a number of methods — we use research, we use lots of ways to talk to customers and get them involved to help illuminate what the end goal is that they're really trying to get to, that at the end of the day, they're hiring your product to help them get to that end thing.\n\nYeah, and along with that, there's often confusion about what user experience design is all about. Really at the heart of that is understanding that end goal for a user, and also what comes before they start using your product, what else are they doing in parallel while using your product, where do they come out, and how well can we stitch this product into their already busy and distracted lives — we all suffer from attention span deficits. So one of the risks is that you have to think about the product in its context — the whole journey, the whole experience, and how it fits in. So there's not just a risk that you're building the right features, there's a risk in whether this product is valuable in the context they're going to be using it in. So we have to pay attention to that — something they genuinely want, and you're the one to provide it to them in a way nothing else can, and that's what really resonates and leads to differentiation and engagement and positive word of mouth — getting that really passionate, engaged user we're all looking for.\n\nIf we can confirm that area of risk — get early confirmation that we're barking up the right tree, that there is value and people want you to solve that problem — then how we solve that problem becomes important. What's the information that needs to be presented at the right time in that experience? Is it complex, is it easy to understand, what's the simplest way to get somebody through that process without more work than necessary? So a lot of these usability risks come to the foreground — given the constraints of the software or the data we're accessing, we're going to design a product that neatly navigates all of that and is really easy to use, doesn't require more time than necessary. So the first risk is value — do they want it. The second risk is usability — can they use it, is it easy, is it a pleasing experience, do they understand how to work their way through the product intuitively, can they learn how to use it quickly and get up and running. Some products are simpler, some are very complex and require training to use across an organization, so that risk will vary depending on the complexity of the product.\n\nA third area: we know there's value, we think our solution is easy to use, but can we actually build it — that's the feasibility risk. That's where our engineers and architects come in around the vision and confirm: can we access the data we need, can we process that in a reasonable amount of time, can we store and secure and scale it. Our feasibility risk is about can we do this. The interesting thing about technical feasibility is that very often that risk lies outside of the product we're creating, because our products interface into a lot of other systems — it could be a back-end financial system, any number of systems we have to integrate with and rely on to create the whole experience. One of the things we try to do really early is some R&D or a proof of concept to say: does this system, this API, do what we think it's going to do, what the documentation says it's going to do? Risk isn't just \"can we create the software,\" it's whether all the other systems we're dependent on are also going to function. There are things we can do to experiment early and collect evidence: yes, we can build this, or yes, people want this, or yes, we have evidence this will be easy to use.\n\nThere's a fourth area that's a little harder to pull out, and that's viability — should we do this, from the client's perspective. Are they in a place where they understand their business model, and building this product logically aligns to what they need at a business level — increase adoption, grow revenues, lower operating costs, streamline communications or supply chain. Are they ready as an organization to support the product? If there's content that needs to be edited or social channels that need moderating, there are roles and responsibilities within the organization they'll have to manage once the product goes live. That viability risk is often hidden, and we help illuminate that as early as possible — this thing going live is going to change your organization in significant ways.\n\nI can think of a couple of examples where the value was there, the usability was there, but when it came to the business model — either pricing or the structure of who's writing the check — that's where we ran into trouble. People ask us all the time: do you ever start working on something, design a solution, and then decide not to build it? One of the reasons that sometimes happens is business viability risk — we can create a compelling product, there are people who want to use it, but we can't find how they're going to pay for it, or what they're willing to pay isn't enough to justify the investment. It's important to unpack that up front — you don't want to get into even an MVP build and realize you have a user but not a customer. Thinking about the difference between users and customers early on, figuring out will somebody pay, how much will they pay, can this transition from a product to a successful software company — that's a big, important question early on. Sustainability — can we keep sustaining the growth needed to hit the marks the business needs to hit.\n\nWe talk a lot within our teams about outcomes over outputs. It's easy to say \"we need software, it could do this and that, wouldn't it be awesome\" — and you're early on playing out feature lists. What we try to do when we engage with a client is the very first discussions are around: where do you need this to move your business, in terms of outcomes, what are the desired outcomes. That's a tricky thing — making a software product is almost like a combination shot in billiards. We can't just hit a button and move your business in this direction, we have to do it through the product. So this question of risk becomes really important — how do we narrow the focus strategically to make sure and test early that if we build this, in this way, with these technologies, it has a reasonable chance of moving your business in the direction it needs to go. Outcomes over outputs is a mantra — don't come in with the solution, make sure we understand the problem up front that the product has to solve.\n\nWhat happens when people ignore some of these areas of risk, when they don't put a process in place to reduce and address them? We do work with people who are so excited about their idea and confident in their strategy that they hand-wave these risk areas. When people don't pay attention to risk, there's an exponential factor — early on, in strategy and design, there's effort to develop your vision, but when we rush forward too fast into a build without digging into these areas of risk, the costs start to mount. You're going to learn at some point, you're going to rush the product to market and then learn — but at that point you've already committed to a tech stack, built the database, built the front-end interface, and it's comparatively more expensive to untangle things that could have been identified very early on. A common scenario: teams work hard to release a product on time and on budget, they get it out, it doesn't do what they hoped in terms of engaging users and building market share, and they realize they built the wrong product or aren't solving the right problem. It could be a beautiful, easy-to-use, well-engineered product, but it's not solving the right problem — and it could be even more expensive to untangle if you've invested in marketing and customer support, because those costs mount higher when you're making significant pivots at that point.\n\nWhat we try to emphasize is how we balance rigor and speed. We do want to move quickly, get to market quickly, get to code quickly so we can see and use and test software — but there are things up front where we look at the biggest risks given those four buckets, and how we can efficiently test that and start collecting evidence that allows the team to pivot when the cost to do so is comparatively so much lower. So the longer you get into your product development process, the more expensive it is to address these risks — they exist, you're going to bump into them at some point, they're unavoidable, so address them as early as possible with as little expense as possible, before you've spent a lot of money, and certainly before you get to building and coding, which is probably the most expensive place to make changes.\n\nYou also implied that not every risk is equally important — how do you deal with that, how do you think about prioritizing risk? There are a number of things we do. At the heart of it, we can't eliminate all risk completely from the process, or it would take too long or be so expensive it would work against your interests in the long run. So we do a lot around prioritizing risk and understanding what's most important. Part of what we do, from a strategic standpoint, is look at assumptions — where are we making assumptions about what users want, how easy something's going to be, whether we can build this efficiently, whether there won't be any surprises. We look along two axes: importance and evidence. How important is this assumption to the success of the product, and do we have evidence that we're on the right track, that these assumptions are right. When you look at risk that way, the team starts to see where the critical assumptions are — the ones that can really sink the success of the project — and that's where we focus.\n\nWe place a heavy emphasis on early prototyping, making sure we're out front collecting evidence that users can use the solutions in the early vision — design prototypes, or proofs of concept where there's some working code behind it, maybe testing an algorithm or integrating different data sources and generating a score. Some early prototypes can be very lean — a spreadsheet, a pretty raw coded experiment in a browser, or a click-through vision of what the design would look like — here's how this person goes from point A to Z and completes the task. Early on, that's a big thing — collecting evidence to make sure we have ample or at least enough evidence, from a lean perspective, to say keep going forward, or start to pivot. We often learn important things in that process — you're close, you're on the right track, but if it doesn't do this, I won't be able to sell it inside my organization. We often run into the question of when a task is complete, when we've completely solved the problem — there's some guesswork up front, we make prototypes, put them back in front of users, and that helps us understand whether we've completely solved it. I helped you find a doctor, helped you understand their availability, when to schedule it — but if I can't finish that off and get it to your calendar, or send out a notification, it's not yet complete. Sometimes you learn things like that along the way.\n\nSo the pattern that's forming is that these product risks are grounded in assumptions we're making — we unpack these assumptions, it's grounded in uncertainty, and the antidote to risk is these insights we try to gain through prototyping, through user interviews, through various means, to begin to gain insight as early as possible that either proves or disproves a given assumption. I very often go in and make a lot of assumptions, but I'm usually not aware of it — I'm kind of blind to my own assumptions, so the team helps me unpack that. And really, through these early insights, we're starting to drive out risk and drive toward some key success factors.\n\nAs we start to reduce risk, we're paying attention to categories of success factors. There's a concept called product-market fit, and that's a common conversation — product-market fit is: you understand the users and their needs, you know how to create value for them, and then you're executing on the solution, so you have a product that's attractive, engaging, easy to use, does the right things. When we can prove that and we have real engagement with the market, that's the golden sweet spot you're looking for — you've achieved product-market fit. Retaining users is usually an important metric to watch — people come in and continue to come back and use it repeatedly, appropriate to whatever product it is.\n\nIs a key metric adoption, or retention, or what would you say are some of the key messages? There are a number of them. Sometimes we know we're getting close to product-market fit even early on, in preparing your market, just based on showing prototypes — you can start to verify strong demand for the product. Retention, once the product is out, is one of the key metrics we look at — people coming in and continuing to use the product, and that will vary from product to product, because in a consumer mobile app, the decision to delete the app from the app store is one thing, versus dealing with licensed software or SaaS enterprise software where the buying decision is made by management and the day-to-day users have to use it. Engagement, customer satisfaction scores are key to that, and revenue is obviously a factor — but when we talk about outcomes, are we really getting traction toward the right outcomes, and the metrics will align, somewhat dependent on what outcome you're seeking.\n\nWhat are some other success factors we pay attention to throughout the process? Software is complex — one that comes to mind is stakeholder alignment. A lot of times we're not just working with a singular client — you might have a VP of Product responsible for the product, but there are many other stakeholders in the organization, from sales and marketing to customer support and regulatory — do they all have the same vision? That really undermines the success of the team trying to design and build the product when stakeholders are all in different places in terms of what they expect and want. Early on, we make an effort to make sure we're all aligned. It gets more complex when third parties are involved, or there's an integration or partnership with another company — those parallel tracks aren't always a hundred percent parallel, and over time you find you're on pretty divergent tracks. There's a lot of effort around alignment on vision and outcomes — that's a big success factor, or it can undermine success. We sometimes work with somebody who says, \"we've had this idea for a while, we just can't get it off the ground\" — one of the reasons they're stuck is team alignment, and by focusing on aligning the team early in the process, it really helps them get unstuck.\n\nRisk is going to vary with every project. These four buckets of risk are present in every project, but not to the same degree — one might be more critical than another. Teams are pretty adept at calling that out and figuring out where the real priorities are. They're not always evenly distributed in neat little buckets, but time and time again, this process of identifying critical outcomes, understanding where the risks are and what assumptions are driving that, and getting in early to test, has proven to be instrumental in the success of our projects. There are lots of examples that come to mind — when it happens, it's pretty magical.\n\nWe were working on a very complex enterprise application meant for some of the world's largest corporations, universities, and hospital health care systems, as a way of assessing and improving their cybersecurity defense — a sober, super important topic these days. They literally had researchers developing some of the smarts around ways to calculate and score progress in these areas, and we were able to get in and help them understand where these risks were, testing it at different points in the process. Very early on, we had an early build of the software, and we could solve at least one of several problems pretty completely, and we wanted to show that — so we were doing live testing with some of these chief security officers from companies all over the world, in different time zones. What we learned was: number one, we were solving the right problems — there was a very positive reaction to the overall usability and user interface. But we learned that while the software was heavily focused on one business unit at a time, the general feedback was, \"this is awesome, but if it can only focus on one business unit\" — when you're a big global company with 13 or 14 business units worldwide, they wanted to be collecting all this data and rolling it up to one global, 50,000-foot view of their security practices. So there's value risk in there, usability risk, technical feasibility — but what we found was we had a great architecture and a lot of good design patterns in place, so the pivot wasn't as difficult as we thought, and it ramped up the value of the product significantly. After we demonstrated that, it took a little time to re-engineer, but it was a critical pivot before the market release. They were able to light up a number of corporate clients they might have had a hard time getting to, and they were able to increase their expected licensing fees for the software, because there was nobody else that did what they did. We were helping these security officers take processes that would take weeks in their organization down to a matter of hours — super exciting, and clearly impacted the bottom line. When we talk about outcomes — much more efficient, much more secure, much easier to communicate upward to their boards — taking a topic like cybersecurity that's super complex and making it simple, so executives and board members could understand where they are, where they're going, how they're getting more secure — that all came out of that understanding of risk and our efforts to address that on the client's behalf.\n\nThat's a fantastic example of how all this comes together throughout the process — that wasn't something that happened instantaneously, it's something we unpacked over time as we learned. This has been super enlightening — if you had one piece of advice relative to this area of risk, as a key takeaway, what would you say is the one thing to remember for somebody thinking about a new product, who sees a hard problem that needs to be solved and is thinking about building software?\n\nI would say that effort — getting the team aligned around the outcomes you're trying to get to, what are the key problems we need to solve — and not getting too hardened or fixed on a particular solution, but understanding that these early experiments are all about getting the evidence that will effectively move you toward the outcome you're seeking. And if so, great — if not, what do we need to tweak. But getting that up early in the process and allowing the team to bring all their creativity, expertise, and ability to navigate the trade-offs — it all comes from that.\n\nThat's awesome. We hope this was helpful and informative as you're thinking about building a great software product. If this was helpful and you'd like to learn more, we're going to continue the conversation in our next episode, where we'll focus on the discovery process — what the process actually looks like and what the steps are. If this was helpful, subscribe so you can get notifications of all the upcoming episodes, and we'll see you there.", "uploadDate" : "2023-01-18T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Darrin Grove and John Beck break down the three phases of product discovery — the essential early work that determines which problems are worth solving and which features are worth building.", "duration" : "PT37M27S", "embedUrl" : "https://www.youtube.com/embed/Ln-uQFq5-9g", "name" : "What is Product Discovery?", "thumbnailUrl" : "https://img.youtube.com/vi/Ln-uQFq5-9g/maxresdefault.jpg", "transcript" : "Welcome back to our Idea Launch series — this is episode two. In our last episode, we focused on the four key areas of risk in software product development. In this episode, we want to talk about how discovery helps reduce risk. My name is Darrin Grove, I'm the founder of Truefit, my background is software development. I'm joined today by John Beck again — welcome back, John, Truefit's Director of Product Design.\n\nOne of the things we hear often is people are so interested in their product ideas that they want to jump right into building something — there's an anxiousness to get into the build. What we recommend is to really start with discovery. Take us from risk to discovery — what is discovery, why does it matter, how does it help reduce risk, and then we'll unpack the key phases of a discovery process.\n\nDiscovery can be a bit of a mystery to people delving into this for the first time. It really comes out of the product management world — the idea of running targeted experiments up front, having a healthy understanding of the risks you face going into making a product — not just software, a tool somebody's going to use to solve a problem, and usually a complex set of problems where there aren't clear, direct answers. What discovery does — the whole product development process, technically, you're discovering along the way, we're very agile, we believe in chunking work into small planned units and always learning, so we can pivot. In a sense we're discovering along the way regardless, but to have an explicit discovery stage up front is to say: for this product, we've identified some specific risks — it'll vary with the product, some are more significant or complicated than others — and we're going to focus on a set of experiments. We take an empirical approach: what evidence can we collect that these things are actually going to happen — if we build this feature, it's going to engage users or help them get a job done, the team knows we can build it, the business knows how to support it. If we can collect that evidence early, we can illuminate issues along the way and make the big-level pivots before we get into the build. That's really what we're trying to do with discovery — test the underlying assumptions that could send you off track if you let that carry into the building.\n\nIs it fair to say discovery is trying to make sure we're building the right thing, solving the right problems? Exactly — it's very much a problem-solving focus. Before we get too far down into the solution, let's make sure we understand the problem and what people need, or what the constraints are — technical constraints, regulatory or legal constraints, constraints from business partners. We don't just have a straight shot to the finish line, we have to navigate a complex set of relationships to get the product to where it can actually be released into the market.\n\nSo the instinct to jump right into a build has to do with speed to market — we need to get a product in the market and start testing it — but as we talked about last episode, that's where things are expensive to change. Figuring out the right thing to build, addressing the key areas of risk, is where to start. The very first step somebody takes with Truefit is a pretty high-intensity workshop we call the Discovery Workshop — the kickoff to the whole process. What are we trying to accomplish there, what would people experience?\n\nYou've got to start somewhere. Part of what we're trying to do in the workshop works on a number of levels — on one level, we're getting to know our client better, understanding their business domain, the market, how they got to the vision, who the stakeholders are. Very early, we try to get them aligned around what the outcomes are — from a business perspective, why do this, what are we trying to do at a business level and product level — entering a new market, reviving a dying business unit, automating a process, countering a competitor, responding to market disruption. We have to understand outcomes early and first, and make sure we know the most important ones — there are often many that are pertinent, but which are the ones we'll be measured against, what does success look like. If we're at the end of this project and everyone's raising a glass and celebrating, what have we accomplished that makes everybody say \"this is a win\"? That's always a lively, fun discussion.\n\nThen we set that aside and say: given our four areas of risk, let's unpack who is the customer who's going to buy this product, and ultimately who's the end user. If it's a consumer mobile app, they're the same person — you go to the app store, download it for free, maybe pay for features later. But if it's a big enterprise app with many users and a complex sales process, a license, distribution across a big organization — that's more complex. In healthcare, we might be dealing with doctors, nurses, hospital administrators, patients and their families, insurance companies — a lot of different stakeholders to map out. We're getting into context, pulling out subject matter expertise our clients have, people who've worked in the field a long time or dealt with similar cases. It's critical that they widen their perspective and not rely too heavily on assumptions. We talk a lot about blind spots — you might understand part of it, but you're missing another key part and how those two are related. We want to collect feedback from real users, because they're not all like you — you might be a subject matter expert, but people use the product in different ways for different reasons. Starting with empathy for the user is fundamental — trying to understand what drives them, what they're hearing, what they're learning, what they're concerned about. Sometimes it's political, sometimes cultural, sometimes emotional, depending on the nature of the product.\n\nFrom there we move into a hypothetical stance — what-if scenarios. If this is what we think the user needs, here's what their current reality looks like, here's how they do it today — often clients are using workarounds that require multiple steps and are a pain, and that's where they see the value of taking six steps down to one. We map that out, and it sets up a hypothetical framework: if we build this, we think it will have this result on this user, and if that's true, it moves us toward the outcome we're trying to get as a business — they'll pay for it, use it every day, tell their friends. That's how we begin to identify the experiments we want to run early on, day one.\n\nHow often do teams come in entirely on the same page versus with a bunch of different ideas, and how does the workshop build alignment on day one? It's very often the case that people tied to an initiative, who have a stake, haven't always gotten in a room together. Some of the collaborative design exercises we do reveal that they have differing visions on where this needs to go. That happens pretty much every workshop when there are a lot of stakeholders — sometimes they're not even in the same company, they're partners providing a piece, like connected device experiences with hardware, sensors, and third or fourth parties on the data side. This is the first real chance to get in the room and connect the dots between outcome and potential solutions, and start digging into assumptions. We don't solve any problems in the workshop, but we flesh things out — coming out of it, we know where we need to go talk to users to understand more about their context, or do a deep dive into technologies and APIs and other services that could be part of the solution. The workshop is instrumental in setting the direction of what discovery comes to look like, but there's a lot of work still to do.\n\nOne thing I remember from when we first met — my engineering background can actually get in the way at this point, because I tend to jump quickly to solutions, what are the features, what does this thing need to do — and the reality is I'm working with tons of assumptions. What we don't want to do is create a solution in search of a problem. You've taught me a new reflex — begin with the problem, why it's important to start with a clear definition of the problem we're solving.\n\nWhen we talk about user needs, a user can have many needs, but they're not all equal — some are higher priority. We're trying to understand those needs in relation to helping them solve the problem, but also understand what other products are in the space, what potential solutions would be distinctive or unique. Are we going to solve all these needs, or is there a subset that paints a picture of a complete product we could build around — day one it might only solve one problem, but there's a rich opportunity to grow and expand. That sets the tone for progressively solving or widening the problem set, which gets into roadmapping and sensible ways to invest and build out the product. Early on, we do things to make sure we understand the problem, illuminating blind spots — you might understand part of it but be missing another key part and how those two relate. What we often find is a relative opportunity factor — not all needs are equal, some are really critical, and when designing a product that completely solves the problem, we want to hit the really critical aspects early on, where we don't have a lot of evidence yet to drive the solution — that's where we focus first. Teeing up problems in relation to risk and priority, then the team can move into the solution.\n\nWe sometimes talk about framing — connecting the dots to make sense of the problem space. Designers do things like understand the emotional journey the customer goes through — a beginning, middle, end, with highs and lows — where are the opportunities to hit those low points and bring them up. Maybe a product is great but isn't solving the full problem — what comes before they use the product, what's happening in parallel, where do they come out of it, do they need to share an output with other people, schedule an appointment, send a status update. Understanding how this product connects to the rest of their life outside it. We do a lot of modeling to understand early patterns for user experience that will help overcome the risks of product value and usability. That also starts a healthy discussion about which technologies make the most sense — is this a website, a native mobile app, both, other pieces of the puzzle — how do we get a consistent experience if I start on my phone and pick it up later on my desktop.\n\nWhat's the output of this upfront problem space? What we're aiming for is a product strategy — here are all the problems we could solve, now let's get them into priority order, these are the most critical things to solve first, and some legitimate problems we might not even address in the first release. That sets up the goals for solutioning — we know we've got to tackle these high-opportunity problems first, each with their own assumptions and risks, some more complex than others, and we want to hit that early before getting too far into the build. That strategy shapes what comes next.\n\nSo now we're ready to focus on the solution — how do we do that? This is where prototyping kicks in — the team digs deeper into what-if scenarios, looking at opportunities to solve the problem in a distinct, valuable, easy-to-use way. We create early prototypes — low fidelity or high fidelity, conceptual workflows that increasingly get more polished, looking like real software with real content — artifacts we can put in front of users to confirm or validate we're on the right track. We often encourage looking at alternative solutions — we could do it this way or that way — and have a conversation with users about which is optimal and why. That hits the risk of value again, and usability — now we have a prototype representing how this product is really going to work, did we get it right? It has an electrifying effect on the team — not just testing assumptions, but building confidence, real empathy — teams can talk for months about \"this is that problem when so-and-so encounters this,\" or \"this is where they run into all this complexity.\" We get empathy, understanding of preference and why, which helps drive smarter technology decisions more confidently based on real insight from users and stakeholders.\n\nHow far do we take the solution stage? One thing we stress up front is that discovery is about experiments and testing assumptions — it is not about completely designing the product up front. That's the difference between an agile process and a waterfall one — we're constantly learning along the way. As we go through discovery, the goal is to get to code as quickly as we can, inserting this experimental activity to hit the high-level patterns and risks and make smart decisions that would be harder to untangle later, but not to completely eliminate risk or let it become a weighty thing that delays the build.\n\nSo we've tested critical assumptions — now we're ready to build? Almost — the last phase of discovery, what we call the alignment space, is to say, based on everything we've learned, before setting off on the build, let's rally around the vision for what this first release is going to be. There are foundations to set in place around data, front and back end, integrations. We now have a good sense of the critical feature set because we put the prototype in front of users and got feedback, and we understand the technologies and constraints. So we close out discovery with a high-level release plan — a transparent, collaborative discussion with the client about which features are in and why, because it completely solves a problem for the user and gets us to market faster. We're not going to build four feature sets right away, we'll build around one or two, set the foundations and critical design patterns in place, which actually gets you into the market faster — you can start marketing, start collecting analytics and metrics that the product is doing what it set out to do. That doesn't mean other features are far behind — we can roadmap first release, second release, third release, with the critical infrastructure in place to make all of that more efficient. It's a real dance — taking a lot of complexity around user needs, technical constraints, business requirements, partnerships, and stakeholder alignment, and figuring out how to move forward with the build while minimizing disruptions. You're always going to be discovering — we're trying to get the bulk of the critical discovery out up front so we can make smart decisions, and continue to discover along the way without holding up the build.\n\nAnother important part of this alignment phase — one of the toughest parts — is that we love working with people who have big visions, but we want to help them start small. That's just good practice, because you want to get into the market, test product-market fit, get user feedback — but the other reality is that usually the vision is bigger than the budget. How do we align the roadmap to the budget? It's about navigating trade-offs — by this point there's real insight the team can look at objectively, knowing we're hitting the right notes, knowing where the rough edges are, knowing a feature has to be there because it reduces certain risks — things we learned in the discovery process. Navigating those trade-offs at a business level means having clarity and transparency, hard discussions — we can do all of this, but not these other things, in the same time and budget. That empowers the client to have a discussion — sometimes it's increasing the budget because now there's a good argument for additional funding; other times some pieces get pushed into a future phase, using today's funding to create an initial product that gets into the marketplace, then getting additional funding approved for follow-on features right away. It's challenging, but there's a lot of magic in that process.\n\nSo we start with the Discovery Workshop and end with what's called the Release Planning Workshop, where the team is now unified, with a high level of trust and clarity, ready to make the decisions that keep everyone on track to launch. Once that's in place, teams can run at high velocity, building with confidence — knowing what the product needs to do, why, and that it's solving the problem in a distinctive way that users will find engaging. The business inside can start preparing for training, marketing, customer support. There's often internal work they have to do, and we're there to help along the way. We'll continue to learn as we go, but the risk factor is significantly reduced as we get into the build. So in discovery, we've clearly defined the problems, we have a compelling product strategy, a solution tested in the market, driving down risk and building confidence, our team is aligned, and we know the phases of the product. Now we're ready to build.\n\nIf there were one thing you wanted folks to take away from this discussion of discovery, what would it be? Really being ready to identify assumptions and get that problem understanding up front — that's the most critical thing, because it drives so much down the road. Understanding where the risks are and validating them — if we're not experimenting in discovery, it's not really discovery. Having a healthy respect for collecting evidence to boost confidence, knowing you're on the right track, and making smarter, informed decisions when it really counts.\n\nThanks again, John — always a pleasure. We hope that was valuable — please join us in our next episode, where we'll take an even deeper dive into the problem space and the solution space, and talk about some of the tools we use to unpack that. If this has been valuable to you, click subscribe so you're notified when we publish these episodes. Thanks again, and we'll look forward to seeing you next time.", "uploadDate" : "2023-02-08T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Darrin Grove and John Beck focus on synthesizing user and market insight into a clear product vision tied to business outcomes.", "duration" : "PT27M29S", "embedUrl" : "https://www.youtube.com/embed/eCg5rPqSJQ8", "name" : "Define Your Product Vision", "thumbnailUrl" : "https://img.youtube.com/vi/eCg5rPqSJQ8/maxresdefault.jpg", "transcript" : "Welcome back to our Idea Launch series. So far we've talked about the risks associated with creating a new software product, and last episode we talked about the whole journey of discovery — why we start there, and how it helps knock down risk and build confidence that we're creating the right product. Today we want to take a deeper dive into making sure we're clear on the problem the product is addressing for the user — let's talk about how we do that. My name is Darrin Grove, founder of Truefit, background in software development. Joining me again is John Beck, Director of Product Design here at Truefit.\n\nThis is really all about defining product strategy. We talked last time about how many people dive right into defining solutions too early — I'm guilty of this myself, probably the engineer in me wanting to figure out the solution and how to build it. But you've taught me to make sure I'm super clear on the problem first. Up front, we've just had a workshop where we're gathering background material, and we're headed into the problem space — we refer to it as \"Understand and Frame.\" Where do we go next?\n\nReally, on one level, we're jumping in to understand the domain — we come to it as product experts, but not necessarily deep experts in the business or user experience domain itself. The discovery workshop is where we come together and take an initial survey of the landscape — user needs, business outcomes, stakeholders, what the market looks like. What we come out of that workshop with is a sense of where the gaps are — maybe we don't understand users as much as we thought, we don't know where they're coming from, what other tools they use, what their experience is like with our product or a competing one. So one of the first things we do is triage the scenario by risk and start diving into pockets based on risk priority.\n\nUser interviews are typically one of the first things we do — an early, usually small, set of qualitative interviews. Qualitative meaning we're not counting numbers, we're unpacking — understanding what their current reality is like. When you're trying to do X, tell me about what you do, how you go about it, where you start, where you begin. We get them to unpack the journey they're going through — what goes well, what doesn't, what workarounds they use. There are emotional and sometimes social aspects too that come out in interviews but usually don't come out when talking to subject matter experts — we want to get to the core person using the product and ask how they feel when things go wrong, or as they're doing a certain task, what's the critical thing they're trying to get past. That gives us a much more rounded understanding — great user experience is often about anticipating where the user needs to go next, and that comes from that deeper understanding.\n\nIn a similar way, when we need to understand stakeholders and the business, the workshop is more about alignment, but we often need to circle back and talk to a VP of Sales, a Director of Customer Support, someone heading up regulatory controls — to understand what's driving the business from their perspective, what success looks like for them, and how the product can hit the right targets. Many software products are really the front end of a whole service the business provides — service design talks about a front stage and a backstage. The front stage is where the user interacts with the business, but the backstage can be complex — think of a doctor's visit, where the nurse checks your insurance and preps the exam room behind the scenes. Service blueprinting maps out all those background steps, what reports or artifacts come out of them, before things get back to the patient. That's the idea of context — the product isn't standalone, it's used by a user in a particular context, and there's often stuff happening on either side of their use of it. We want to pay attention to all of that, because it's a hotbed of opportunity — insights about the rhythm of how software works in someone's life, like submitting something and needing a quick response, or notifying other parties about the next step in a transaction.\n\nEarly in the project we want to take a divergent path — poke down every hole we can around user needs, stakeholder needs, the market, the technology, the business — and then start converging toward meaning and priority. Understanding the market matters too — sometimes it's very competitive, and we need to understand table stakes and how the product will differentiate from things that have been out there longer. How often are people even aware of the competitive landscape? We often hear \"there are no competitors, we're on our own\" — but when we look, we find people offering solutions. Competitors aren't necessarily a competing business — there are solutions out there competing for your target user's attention. Sometimes your competitor is a paper day planner, or a phone-based service — other ways of solving the problem. We spend time looking at analogous services too — not direct competitors, but parallels, like how Netflix distributes content or how Zoom handles video conferencing — to find useful patterns that generate good ideas about the solution.\n\nIt's a creative process — we're going wide, looking at the whole landscape, exploring. It's a fun part of the process — you learn, and sometimes you bump into things you didn't expect, and that's okay, we want to learn those too. Throughout this, we're still paying attention to the experiments we talked about in the previous episode — we begin with empathy for the user, make some assumptions, and then when we get to interviews, we're proving it out — maybe we learn we didn't make good assumptions, or maybe it's more nuanced than we thought, with differences between users that can have conflicting interests.\n\nSo we've looked at the market, looked at the user, and now we need to make some decisions — get to a point where we're defining the problem. There's a point, varying with complexity and risk, where we can't go down every avenue — we're on a timeline, we have to make smart decisions and inform the process as best we can, but there's a point where we go from diverging to converging toward a strategic recommendation. Designers start mapping key patterns — journey maps, experience maps, or something called a job map, which breaks down all the steps needed to complete a job or task, each with mini-goals, some going well, some not. We take those problems we've uncovered and reframe them as opportunities to create value. That's where we discuss what would be most valuable if we could do it in software — software doesn't solve every problem, so we think broadly about the user's total journey and where software can play a role, then break down where those opportunities are.\n\nCan we get early feedback? We talked about user interviews — smaller sets, done more often. There's a point where it helps to put together a simple survey and get quantitative data — we spent time with users like you, here are the needs, help us understand the importance of these needs and how satisfied you are with current solutions. That gives important insight to drive strategy — not all problems are equal, some needs are more important to solve than others, which helps the team focus strategy for the first release. Priorities start to emerge — users need X, Y, and Z to complete this job, and we could build a product around just those pieces, while knowing we can address other problems over time and grow the software. Helping a client navigate those trade-offs, informed by research, is really what informs product strategy — it's a dance, but super valuable to do up front.\n\nProduct strategy is combining everything we've learned about the user and how they solve the problem today in their whole context, the competitive landscape, products or competing processes in the market, industry trends — bringing that together and prioritizing which problems we're going to solve, while keeping the whole team, including the client's team, aligned on the problems being solved.\n\nSometimes it's like playing pool — a combination shot. We know we're trying to move the business in a certain direction, but as a product team we can't just dial up customer revenue directly — we have to do it through the product. So given the problems we're solving, what can we do in the product that moves the business in the right direction? This process aligns high-priority problems to solve with that movement, and we need to flesh out how we'd do it and what the solutions are as we move forward. Making those choices is hard — once we know the highest areas of opportunity, we bring that to the surface early and get everyone aligned. Product strategy is really about the mission of the product — what features most likely align to that mission, and therefore what needs to happen underneath the hood — an integration, a database, algorithm development for scoring. The vision for what that first release needs to do starts to come together.\n\nCan you think of examples where this work led somewhere unexpected — different from where we started? We worked with a legal product that had a really smart search engine under the hood, and they wanted to turn that into a product. Through discovery, it became less about just the search and its results, and more about how to organize those results, package them in a way the attorney can control, take a subset to recommend to a client, communicate it, keep it secure — aspects of the experience they hadn't considered yet. That came from understanding what the end user of the software would really need — it's one thing to do great search and present results clearly, but understanding how it needs to be packaged, shared, and secured opened the client's eyes to more than they originally expected. Early prototypes, put in front of attorneys who'd use the software, validated that we were really thinking through the end of the road, not just the search itself.\n\nI'm thinking of another project we're about to launch, in the fitness space — a really successful leader in that space had done some work on an existing mobile app that wasn't going well, and wanted to take it to the next level. As we dug into the problem space, we realized — and he realized — he wanted to solve a whole different problem, going from one direction to a completely different product vision we began to validate. Now we're launching a product that looks very different from where we started in the discovery workshop — a great example of how user interviews and competitive analysis can change the trajectory of a whole product. We're also working with someone right now who realized there were a lot more competitors than he thought, so now we're paying more attention to differentiation and going deeper into certain feature sets based on what other products in the market are doing well or not.\n\nHow do you come up with the right problems to solve? Seeing the relative value — we could go down path A, B, or C. We came into a project thinking it was A, but real evidence showed the real opportunity was B — high value with the user, differentiating in the market, technically feasible, supporting business goals. Identifying that early and aligning on the direction is the goal.\n\nIf there was one key takeaway for this problem space, what would it be? Part of the magic of \"Understand and Frame\" is using it to expose blind spots — giving discovery the opportunity to do its job and let insights emerge. I'd say: give it time. We balance rigor and speed — we don't have all the time in the world, we're trying to move quickly, but you want to look down multiple avenues to create value, and let the evidence you're collecting drive strategy, rather than relying too heavily on assumption right out of the gate. Being able to look through multiple lenses — user needs, market, business, technology — pays off down the line as teams thread their way through the optimal solution.\n\nI'm glad you said that, because for me this is a point in the process requiring a lot of patience — curious, eager to learn, but we're not talking about solutions yet, and everybody wants to jump right to solutions. It takes patience, because making sure we solve the right problems pays off down the road in user adoption and everything else you want at the end.\n\nThanks again for joining us for this episode, where we went deep into product strategy. Join us next time when we move from the problems to one of my favorite parts — the solution space — and take a deep dive into how we create solutions. Looking forward to seeing you then.", "uploadDate" : "2023-03-15T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Darrin Grove and John Beck walk through turning a validated problem into a concrete, testable solution.", "duration" : "PT27M29S", "embedUrl" : "https://www.youtube.com/embed/ChxWbqFkqhA", "name" : "Prototype to Test and Learn", "thumbnailUrl" : "https://img.youtube.com/vi/ChxWbqFkqhA/maxresdefault.jpg", "transcript" : "Welcome back to our Idea Launch series, where we're focused on helping you create better software products. This is episode four. In our last episode, we took a deep dive into the user and the market, and tried to unpack the opportunities to create value. Today we're going to focus on solutions. My name is Darrin Grove, founder of Truefit, background in software development. Joining me again is John Beck, Truefit's Director of Product Design.\n\nToday we're looking at solutions in two parts: generate and prototype. After we have a vision for the product and know what problems we're solving, what are we generating? Simply put, solutions — and a lot of times people think of this as brainstorming, but there's a method to it, and doing it rigorously early on can be key to success. One of the things we really try to emphasize is approaching this as a team sport — you have a sense of where the opportunities are, you've spent time talking about risk, talked to people, and have a sense of how to create value for them. The key is getting your team to tackle generating solutions together, from different perspectives — not just designers, but the product owner, engineers, architect, QA people, all coming together to generate solutions.\n\nFor any given problem, there are multiple ways to solve it, so this is where we get creative and diverge to find lots of different possible solutions. It helps to go in with a healthy respect for your own biases — everybody has technical or creative biases, certain beliefs — and you don't want a one-and-done \"how might we solve this\" with a single solution. You want to push the boundaries, crack through that layer of bias and predictable patterns, because that's where the more creative solutions are, but it takes some work to dig them up.\n\nWhat's the goal when generating solutions? You've pulled the team together, you have a good sense of the opportunities, now you're solving them as a team. There will be obvious low-hanging fruit solutions, but you want to push through that and use some process to get the team to bring great ideas forward. One thing we really emphasize at Truefit is that good ideas can come from anywhere — from those close to the user, or close to the technology, who know what's possible. To bring a bit of structure, we recommend teams start with statement-starters, sometimes called \"How Might We\" statements. The key is that you're not defining the solution in how you write it. For example, in a system tying together a doctor, therapist, admin, and patient, an early \"How Might We\" might be: how might we reduce the effort a therapist goes through to sign up and create patient accounts, or how might we make it easy for the admin to document what the patient is doing for insurance submissions. You write it in a way that doesn't define the solution, then let the team generate — generally we try to identify two or three solutions, not just the first, most obvious one.\n\nSometimes it helps to think about analogous experiences — how might this work more like going to a fine restaurant, or purchasing movie tickets or an airline ticket when that's a good experience — applying those things to this space shakes up the team's thinking and can generate creative, valuable solutions.\n\nAfter a Design Studio session, there's a bunch of ideas, a bunch of \"How Might We\" statements — what's next? It's an exciting time — you've got stickies, sketches, everybody's starting to see it. I love that period — it's been abstract up to this point, and now the ship is starting to emerge from the fog, you can see it, it's becoming tangible. But now you have to sift through as a team — not all ideas are equal, and you know that going in — you've thrown out some really practical ideas and some wild, crazy ones, hopefully. So we start to prioritize those ideas as a team. The key here — if you've listened to earlier episodes about risk and outcome — is for the team to ask: how well will this idea or potential solution impact the outcome I'm trying to get to? After that discussion, certain candidates start to emerge — through a voting exercise or open collaborative discussion — connected back to the outcome that's critical to the product's success.\n\nThe next thing we often do is flesh out the most promising solutions enough to get under the hood and see how they'd potentially work. Early on, a team might encounter information architecture questions, user flow and interaction questions — we hit it at a high level, going wide, testing alternative paths. To put some meat on the bones, at Truefit we use a process called Object-Oriented UX — identifying the objects in the experience the user will encounter. In the patient/therapist example, when the patient comes into the software, they'll see things like a workout regimen, a calendar, information about their therapist, documentation of their progress toward an insurance goal, some indicator of compliance with the program. We model the real world — the objects in it — and marry that up with the solution. It's helpful to log what objects the user encounters, what properties those objects have, and most importantly, what calls to action exist — I can create a profile, edit a profile, delete an account, archive a patient. That builds a mental model of how the software might work — it's early, sketchy, working in stickies and whiteboards with arrows and notes, building an interaction model for how a user might flow through tasks.\n\nWe're looking to build early use cases by role, because in many cases these systems are complex — a website, a native mobile app, a device, a separate admin tool, all built from a common architecture and common data. We identify the objects, link together how you move through them, but break it down by user — how does a patient receive their first workout and know what to do, how do they get guidance, what can they see afterward. We literally write down use cases: a patient receives their device and sets it up at home; a therapist logs in and sees the progress of all their patients at once, working to identify problem cases; a surgeon logs in less frequently but wants to see overall how patients are doing on reducing pain or recovering motion. Those use cases become helpful in setting up user flows — another layer of detail, framing out how the patient signs in, what they see the first time, where they review their workout — referring back to the use cases and blocking it out. A user flow lets you bring the data and interaction with the software into a series of screens, playing out to some successful completion.\n\nUser flows are the first representation of screens and how you'd navigate them, and the purpose of each screen. You start to see common patterns, templates. Is a wireframe the same as a user flow? A wireframe is a low-fidelity representation of a single screen — focused on how data is presented and how the user interacts within that screen. A user flow stitches those screens together to model successful completion of a task. That's really your Eureka moment in software — the first place you go, \"now I see it.\" First your team sees it, then stakeholders start to see it, and questions sink in — is this too complicated, can we shorten it — but now there's something tangible to look at.\n\nSo we have user flows, the product's coming to life — are we ready to prototype? We're usually chomping at the bit to get to the next step, but the one thing I'd advise at this point is, now that you have some detail to look at, we place emphasis on testing your assumptions — and to test them, you have to identify them. Your user flow is a great way to start revealing those assumptions. One trick we learned is to state assumptions in the positive, because it's easier to test them that way. Looking back to our earlier episodes about risk, we had four lenses — and that's exactly how we look at assumptions here. There are assumptions about value — will somebody want it, will a therapist value this feature because it saves them time — and assumptions about usability — will a patient understand their end-of-session report. That's an important theme throughout the entire process — we're always keeping the four areas of risk in mind. Everything we're doing is a test — testing assumptions, testing hypotheses, bringing more insight to the process. You'll generate a lot of assumptions, and that's not a bad thing — as a team, you want to go through and find the critical ones. You're always prioritizing — what's most relevant to the software's success, and what evidence do we have that it's actually true. Where those two come together — something super important with zero evidence — those are the critical assumptions to test. If you have fifty assumptions, identify the five or six leap-of-faith assumptions the product's success is hinging on.\n\nRather than jump straight into a build, are there simple tests we can create? That's where prototyping comes in — once assumptions are identified, what's the appropriate form of prototype to get evidence you don't otherwise have? At what point do you introduce brand styling and higher-fidelity visuals? That's relative to what you're trying to test. There are many potential types of prototypes. If you're testing the value of a feature, a storyboard is a nice way to use narrative — telling a story about how a patient receives equipment from their therapist, goes home, does their workouts successfully without leaving the comfort of home. Storyboarding stitches together multiple touch points — the web, a mobile app, a device — and lets you tell that story at a high level, or variations of it, giving you an early prototype to test with users. Storyboards are higher-level than user flows and screen designs, because you're testing value — is this something people would want.\n\nIf you want to get under the hood and test usability — remembering we haven't built any software yet — there are simple tests we can do, sometimes just with wireframes, testing discoverability or navigation, how you'd get from here to your profile, without needing a complete, fully interactive click-through prototype. We keep coming back to: what's the fastest way to collect evidence, get in front of end users, get feedback, and drive strategy forward. Sometimes, though, you need to understand how users react emotionally to the brand, content, look and feel — in those cases we make a high-fidelity prototype, digging into early representations of style, using realistic data and content, to see if it resonates and hits the right notes.\n\nSo there are multiple ways to prototype, and we try to do it as quickly and as small as possible to test our assumptions. What about a feasibility risk, something very technical? When we really have to play out a feasibility issue — can we integrate a technology into our existing platform, integrate different APIs and data sources to affect a scoring algorithm — no amount of design prototyping answers that question, so we create a proof of concept. It may not look anything like the end product, but it proves technical feasibility — like testing whether we can integrate a third-party video conferencing tool into a native mobile app by picking leading options and running a coded test to see how well it works. We do one or more proofs of concept to knock down technical risk and make sure we understand how a solution will actually work — will this API return the data we think it will. Running those early tests can have a hugely beneficial impact later in the build, because we find things early. We once had a vision for a cruise-planning app that hinged on lots of nice photography, and we had a data source for it — but until we ran the proof of concept, we learned the photography we had access to was all very small resolution. That vision of automatic high-quality imagery had to be adjusted — the kind of thing you want to learn very early, and we were able to adjust our design approach because of it. Early proofs of concept have proven extremely valuable in reducing risk and surprises later in the build — a week or a short period of deep-dive effort from engineers can have a giant impact on the product down the line.\n\nThis is an exciting point in product development, because now we have a prototype that can be used for early customer development and demos — sometimes in an investor pitch deck too, not just for testing and knocking down risk. What are some key takeaways? Approach generating ideas and solutions as a team — good ideas can come from anyone. Apply a little rigor and structure to go wide — this may be the most opportune time to do that and test alternatives. Dig into the assumptions — sometimes they're hidden — and identify and prioritize the ones most critical to the product's success, and let that drive your prototyping strategy. If value is the most critical thing, a storyboard might be enough; if there are deep technical feasibility and usability risks, you might need a full click-through, high-fidelity prototype and one or more coded proofs of concept. The answer to scoping your prototypes is the type of assumption you need to test.\n\nThanks a lot, John, this is super helpful. If you found this episode helpful, please subscribe and share it with someone working on a software product. If you have an idea for an interesting problem to solve, reach out to us at truefit.io — we might feature it in an upcoming episode. Join us next time, when we go into the third phase of the discovery process, focused on validating our assumptions and aligning everybody around the game plan going forward. We'll see you there.", "uploadDate" : "2023-04-28T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Darrin Grove and John Beck cover validating prototyped solutions with real user evidence before scaling.", "duration" : "PT24M42S", "embedUrl" : "https://www.youtube.com/embed/3-0raNUbMag", "name" : "Chart Your Path to Market with Confidence", "thumbnailUrl" : "https://img.youtube.com/vi/3-0raNUbMag/maxresdefault.jpg", "transcript" : "Welcome back to our Idea Launch series — our goal is helping you create better software products. This is episode five. Last episode we looked at the solution space — generating and prototyping solutions. Today we're going to talk about what to do with your prototype — how to test it, and how to get your whole team aligned and ready for the build. My name is Darrin Grove, founder of Truefit, background in software development. Joining me again is John Beck, our Director of Product Design.\n\nWe've worked through Understand and Frame, talked about solutions, which ends with a prototype you can use for all kinds of purposes. Now let's talk about what to do with that prototype — validation and user testing. Why are we doing that? This is a challenging phase, but it's really the meat of what discovery is all about. In the validate phase, we're testing our critical assumptions, primarily collecting evidence — putting our scientific research hat on as a team. This isn't a dissertation or a PhD — it's about effectively going out and collecting evidence that we're on the right track, putting proposed solutions in front of an end user. The big things we're validating: is this a solution somebody wants, is it going to effectively solve the problem, remove a burden, advance them toward completing a task, working efficiently, saving money. This is when you get feedback on whether the solution from the last phase is going to solve the problem — it might be yes, it might be no, and you need that evidence. There's real value in quickly getting that evidence — confidence for the team solving these complex problems, and confidence for decision-makers approving budget or managing the overall product or business strategy — keeping in mind we want successful product-market fit when we launch, and this evidence shows whether it's going to fit the market and achieve our business outcomes. This is where the team gets a chance to rally around the vision — we're going to do this before something else, and here's why, grounded in actual evidence, getting stakeholders aligned.\n\nWho are we testing the prototype with? We talked before about the types of prototypes we make and what we're trying to learn. We apply lean research and lean product development methods — by this point we have at least a root understanding of who our user segments are, and we try to get exposure to maybe five or six potential users per segment. Using our physical therapy platform example — a studio therapist is one segment, patients another — can we get in front of a couple therapists, doctors, patients, admins. Methods can be qualitative — typically interview-based, giving the moderator a chance to show a prototype, ask the user to do something with it, probe deeper on usability and preference. Or if we need a broader sample, questions about how much somebody wants something, quantitative survey-based methods can get to larger samples — twenty, thirty, or higher — testing market response across different regions, urban versus rural, and so on. Is this also when we'd test pricing and willingness to pay? Yes, that's often one of the things we're trying to validate, whether qualitative, quantitative, or both — there's always a balance between how efficiently we can collect evidence and moving on to preparing the team for the build.\n\nWhat are some classic examples of things learned testing a prototype, maybe something surprising? This is where your biases and assumptions about how something's going to work can get a cold splash of water. Using storyboards to gauge value and the likelihood a feature will satisfy a prospective user, you can learn two things — certain features test really highly, users give green lights, big thumbs up, \"if you build that I will use it and pay for it\" — super valuable. But equally valuable is \"I don't want that, I don't see any value in that\" — knowing what to drop from the list, make secondary, or push back in the release plan, can have significant impact for the team. Sometimes quantitative surveys reveal feature priority preferences, or differences between segments — we worked on a therapy product where we wanted to understand generational differences, and even the idea of using technology to connect you to a care team monitoring you at home — people had very different attitudes based on generational lines. A survey reveals that, and with quantitative methods you can score and compare across brackets — gender, income, education lines.\n\nOn the qualitative side, we worked on a legal tool — software to help a patent lawyer prepare a case by researching patents, with some smart search and natural-language-processing technology under the hood. But where we got great feedback was on how an attorney stitches that work into their day-to-day workflow. Sitting with attorneys at different practices and firm sizes, we learned they wanted to control the results of their searches — not showing a client everything, but the most relevant results, so they needed the ability to collect all results for themselves and then segment part of that to share with the client. Those insights have huge impact on whether something needs to be prioritized in the first release — and the reason this matters is we're doing this with a smaller prototype, a storyboard or click-through, before the more expensive process of building anything. This is the least expensive time to make changes to the design, feature set, and software — finalizing and prioritizing the feature list before spending time and money to build.\n\nSometimes the software is complex, but the environments it's used in are also very complex and diverse. We've done cases with enterprise software where we demonstrate the core functionality up front and use interviews to understand that you'll have to know how to sell this software into one type of environment versus another — value in both, but the insights help shape not just the product but the go-to-market strategy, understanding that certain features might be required in one environment or adjacent market. We might strategically decide to focus on one market for the first release, get to product-market fit, then shift to another market and introduce additional features. That kind of insight early has huge implications for product release strategy and overall go-to-market strategy.\n\nSpeaking of release strategy — we've gathered all this evidence, now we go into story mapping and release planning, kind of like landing the plane. This is the culmination of discovery, turning insights into a real product roadmap. What is story mapping? The best approach is again as a team — we identified opportunities as a team, moved into solutions, identified critical assumptions, and now we've learned whether we're hitting the mark or not. We don't necessarily fix what's not working right away — we can put a pin in things, say this is fully ready and should be prioritized for release, or this is on the bubble and might not make the first release. Before fine-tuning solutions, we bring the team together to focus on a more nuanced version of what the product features actually break down to be — what's the work ahead. Story mapping, common in the agile world, identifies what features align to the critical problems we're addressing for the end user. In our therapy platform example, we know we have to create value for the doctor, the surgeon, the therapist, the patient — but what's the minimal set of functionality that solves the problem for each of them, and maybe there's an admin in the mix too. Story mapping is a great visual framework — in person, we dedicate a big chunk of wall space and put up stickies: here's the problem we're solving for the user, here are the associated features, and details determining whether something is a small, medium, or large solution. That gives the team a chance to discuss what's priority number one, what's a differentiating feature — there's lots of argument about what's in the first release, whether it's differentiating, whether we have evidence users want it — and we do, because we proved it in validation, this is something they want and will pay for. This sets the stage for subsequent features added later — bedrock, but this is also where things get challenging, because we work with a lot of business leaders who have big visions and see everything that's possible far down the road. We love big visions, but we help people start small — as small as is practical to test product-market fit — and the one big thing you always have to wrestle with is budget and timeline.\n\nWhat are other challenges with getting everything aligned? \"Minimal\" is relative — it depends on the nature of the product. A single entrepreneur with no preceding product and a new market to explore might start with a really small kernel of features. A bigger enterprise app facing a complete retooling of an existing app can find it very difficult to remove features — minimal might mean improving existing features in a rewrite while adding just a few new ones, with clear reasoning for why that set was minimized. Understanding trade-offs, visualizing the work into columns and rows, aligning that to budget and timeline, and pulling stakeholders into the discussion — everybody values the visibility, and there's a kind of magic in saying \"we have to make concessions somewhere, pull some things out of the first release\" — it doesn't mean they won't get built, just that they're prioritized for a later release, and we feel confident making that recommendation because we have actual evidence grounding the decision. Getting stakeholder alignment at that point is absolutely critical — that's the essence of product strategy: this is what the product will do and won't do, and why, these are the goals we're trying to hit, and this is how we'll measure success — that's why we call it the alignment space, because you're getting everybody aligned.\n\nKey takeaways: applying lean research methods to validate quickly, sometimes making trade-offs around smaller sample sizes to get to insights that inform decisions — it's about collecting evidence and letting it speak for itself, not ignoring what it's telling you, even if it says something is okay but could be better, which paints a picture of what \"great\" would look like and lets you account for that in the release plan. Visualize the work ahead in a story map, and use that to align your stakeholders.\n\nWe've made it to the end of discovery, with a strong product roadmap and release plan — ready to start the build. This is exciting — we've taken a lot of risk out of the product and given ourselves confidence it will achieve product-market fit and hit business goals. The learning doesn't stop — we're agile, you have to continue learning — but the big risks around alignment, user value, and technical feasibility are dramatically reduced, giving the best chance for success.\n\nThanks, John, this has been a good conversation. Thank you for joining us — if you found this episode helpful, subscribe and share it with a friend who might be solving an interesting problem with software. If you have an interesting software idea, we'd love to learn about it, and who knows, maybe we'll include it in a future episode. Please join us for our next episode, where we move from discovery into the build and start talking about how products actually get built. We hope to see you there.", "uploadDate" : "2023-06-30T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Darrin Grove and Dominick DeStasio, who served as Truefit's COO, open up the build stage, covering cross-functional teamwork and agile development.", "duration" : "PT25M53S", "embedUrl" : "https://www.youtube.com/embed/vRUjrEecwH0", "name" : "Build Your Product and Continue Learning", "thumbnailUrl" : "https://img.youtube.com/vi/vRUjrEecwH0/maxresdefault.jpg", "transcript" : "Welcome back to our Idea Launch series — our goal is to help you create better software products. This is episode six. Last episode we wrapped up the discovery stage — getting the whole team aligned, deciding what features to build. In this episode we're jumping into the build phase and talking about the process of creating your software product. My name is Darrin Grove, founder of Truefit, background in software development. Joining me today is Dominick DeStasio — Dom served as Truefit's COO, and was the guiding force behind the process we use here to create software products. Welcome, Dom.\n\nLet's recap who's on a cross-functional product development team. We have a product owner, designer, architect, two to three engineers, and a quality assurance person doing testing. What does a product owner do? It's an official Scrum role, a bit different from how it's officially defined in Scrum — it's project management and product ownership, making sure clients understand the purpose behind features being built, helping them make good, solid product decisions, and looking at the product as a whole. What do designers do? Our designers are full product designers — UX, UI, research — with all the skills to make sure user needs are met and users are at the center of everything. I liked what John said in a previous episode about the whole team being part of the design process — everyone brings expertise and a voice that informs a more robust product definition. What do software architects do? They make sure the code is sound — building something scalable that meets user needs, is flexible enough to adapt as we find product-market fit, but has a really strong architecture at the core. It's not uncommon to see products where the architecture wasn't well thought through, things just got tacked on, and eventually the whole thing needs to be rebuilt.\n\nIs it possible to over-architect a solution? Certainly possible, and the answer varies dramatically based on the product — some have a pre-existing domain where you know where you're going, others are more exploratory. The product owner helps the client understand trade-offs and make good decisions about where to spend money, how deep to go in architecture early versus finding things out later, with the understanding that may mean more or less rework depending on the situation. Everything is business-contextualized — what's the best thing for the business, for the product.\n\nSo there are developers and testers, rounding out a cross-functional team. Outside that core team, what other roles influence product direction? There's always somebody in a key product management role for the client — someone with authority to make decisions, spend money, decide direction. Sometimes that's an entrepreneur with an idea and a small team; other times it's a dedicated product manager working with a group of stakeholders. Sales is another role — getting market feedback, talking to customers throughout the process, which helps inform where we're taking the product and informs their sales strategy. There's a rich feedback loop when doing customer development or selling the product early and getting market insights.\n\nComing out of discovery, we've got a release plan, a product roadmap, prioritized features. Now we're ready to start unpacking those and building in code. How does the work get organized — what's a day or week in the life of the product development team? Coming out of release planning, we have a high-level understanding of how to prioritize the backlog and phase the product to market — but that breakdown is still at a reasonably high level, we're not going to detail every little thing that won't happen for months. From there, we work down the list and dig deeper — the team gets together, we work in one-week sprints, with a review with the client every two weeks (every two sprints, to cut down on meetings). We have a sprint planning session, breaking down the top items into details — any feature from release planning may break into two, three, five, or ten user stories. We don't want to say \"we'll talk to you in a month when this giant feature is done\" — we break it into pieces that fit inside a one-week sprint, and inside those sprints, software is built, peer-reviewed, and tested. Coming out the other side, we have a piece of usable, tested software — maybe not complete, but an increment of the larger feature that's usable and solid. There may be rework later as other pieces come together, but we're making progress customers can see. At a high level we're working off release-plan prioritization, though there's always some flexibility — laying groundwork for other things, making sure the team stays full — but generally we're building off that plan, measuring and learning as we go, and tweaking the release plan if needed while working down the list in priority.\n\nWhat does a Scrum Master do, and what's the daily rhythm? The Scrum Master makes sure the team operates efficiently — while the product owner works closely with the customer and market to make sure we're building the right thing, the Scrum Master helps the team operationally, removing blockers, doing whatever's needed to keep things running well. How does story estimation actually work in real life? The earlier you are in development, the more margin of error in estimating — more unknowns, you haven't gotten into the detail yet. As you go, the picture gets clearer. Estimating happens the whole time — just because we don't know enough doesn't mean we can't estimate, we have to do our best and refine as we go, based on complexity informed by years of experience across thousands of products. Who estimates? Early on it might just be an architect, for high-level planning; once we're in sprints, the team estimates together — it's as much about the conversation as the number, hearing \"this is really hard\" from one person and \"this is easy\" from another, or \"what about this edge case nobody thought about.\" We try to make everyone comfortable giving an estimate without one person persuading another, because we're trying to get to the real answer and the reasoning behind it — there are always ways to make a feature more or less complex with trade-offs, and good conversations with clients about which path to take, or whether to break something off as lower priority for later.\n\nHow do teams measure progress? There's no single answer. One measure is quality — baked into the process from the start, not many bugs, not customers finding things wrong after the fact. We have a very high bar on quality and stability. We're also tracking whether we're on pace with the time window and story points needed — but that has to be married to quality, because you can convince yourself you're going fast while pushing problems to the back end. That's part of why we don't count points as done until they're tested and rolled out and we feel good about it — some teams look good on paper but nothing actually gets delivered, so we take a holistic view.\n\nWhat happens a few sprints in when new information impacts the release plan? We expect that to happen — it's build-measure-learn, core to agile. As you build and move, you uncover things, and the product and team need to respond to that. The product owner figures out the priority — sometimes it's not a big deal, sometimes it's a more substantial change we have to plan around. Our goal is to uncover changes sooner rather than later, because the further into a build you are, the more costly substantial changes become — that's part of why we put things in front of users early in discovery and continue to get feedback during the build. There are always business reasons why that's not always possible — markets change and we can't control that — so it's about figuring out the impact and re-prioritizing the backlog. We don't come out of release planning and never touch the plan again — we pay attention to what we're learning and adjust to make sure we're not just following the plan off a cliff.\n\nI remember a client we worked with on a large order-management system — midway through the build, a competitor released a new product, and we had to decide together whether to integrate with that other solution or duplicate it. We made a good decision to integrate, which saved a lot of money — a dramatic example of a planned feature suddenly being delivered by someone else. The important part is that decision was made together with the client — working through the pros and cons, the risks and upside of each option, making a sound business and product decision jointly, and making sure there were no surprises, communicating clearly at the time.\n\nWhat are the trickier curveballs, beyond just sprinting smoothly through the backlog? Almost all of them involve third-party dependencies — a vendor we're integrating with, a hardware manufacturer for a wearable, or similar. Since we don't fully control those, we look further down the backlog to spot things that could become blockers, and lay groundwork ahead of time — alerting a partner or vendor about deadlines, doing prep work — to try to neutralize snags without doing unnecessary work too far ahead. Third-party dependencies are the hardest part because we're out of control there, but when snags happen, we can adapt, work on other parts of the product, and communicate the trade-off with the customer — that's normal in small doses; the risk is when it becomes a prolonged, protracted problem.\n\nEarlier you mentioned only breaking down details for items at the top of the backlog, because everything further down can change or get de-prioritized — that's a matter of overall efficiency and flexibility. We can't ignore the lower-priority items entirely, since we need enough understanding to estimate cost and see how things fit the product and user needs, but we try not to go deeper than necessary at any point, because things can change and that work would go out the window anyway.\n\nIf you had to summarize this into key takeaways — what advice would you give someone thinking about the process they want to use? Build a process, and work with somebody who expects change and has a process geared around keeping you in the loop without surprises. It's a fact of product development — unless you're just replicating an existing product with no interest in learning from users or the market, things are going to change, the market will shift, your business situation will shift, and you have to be able to adapt. Working with a partner who expects everything to stay fixed and isn't geared to respond to change doesn't help you. For us, it's as much about making sure clients understand the decisions being made and feel empowered as part of that process — because at the end of the day, it's their business and their product. We spend time making sure they don't have surprises, that they understand why these things happen and that a lot of it is normal — much of it is educational, helping clients get to a place where they know how to respond to change through working with us, because it's not just something that happens early in the build, it's regular, especially today when software and markets are changing so fast.\n\nExpect change, have a structured process — thanks, Dom, awesome conversation, and thank you for joining us. If you found this episode helpful, subscribe and share it with a friend working on a new software product. If you have an idea for a new software product, we'd love to hear about it — reach out to us at truefit.io. Please join us for our next episode, where we're going to dig into some technical details, talk about R&D, maybe talk about some code — we're going to have some fun and get nerdy. Hope to see you there.", "uploadDate" : "2023-08-09T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Most failed software launches aren't a technology problem — they're a problem of building something nobody needed. This short breaks down how to trace user symptoms back to the actual problem worth solving.", "embedUrl" : "https://www.youtube.com/embed/PsIhGXayaRM", "name" : "Identifying Key Problems", "thumbnailUrl" : "https://img.youtube.com/vi/PsIhGXayaRM/hqdefault.jpg", "transcript" : "If you had one piece of advice relative to this area of risk, what would you say is the one thing to remember for somebody who's thinking about a new product, who sees a hard problem that needs to be solved and is thinking about building software? I would say that effort — getting the team aligned around the outcomes you're trying to get to, what are the key problems we need to solve — and not getting too hardened or fixed on a particular solution, but understanding that these early experiments are all about getting the evidence that will effectively move you towards the outcome you're seeking.", "uploadDate" : "2024-08-15T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Discovery only has value if it turns into a plan a team can execute. This short covers the handoff from discovery insight to a prioritized, buildable backlog.", "embedUrl" : "https://www.youtube.com/embed/N7Sh1tP9rSw", "name" : "We've Gone Through Discovery, What's Next?", "thumbnailUrl" : "https://img.youtube.com/vi/N7Sh1tP9rSw/hqdefault.jpg", "transcript" : "Done at Design Studio, there's a bunch of ideas, there's a bunch of \"how might we,\" what's next? It's an exciting time — you've got all these stickies, you've got sketches, and everybody's starting to see it. I love that period in a project — it's been so abstract up to this point, and now it's like the ship is starting to emerge from the fog a little bit. You can start to see it, and it becomes tangible. But now you have to sift through as a team — not all ideas are equal, and you know that going in. You've thrown out some really practical ideas and some really wild, crazy ideas — hopefully you have some of those. So we start to, as a team, prioritize those ideas.", "uploadDate" : "2023-08-18T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "The best product ideas rarely come from one department. This short covers how Truefit builds space for engineers, designers, and customer-facing teams to surface ideas that shape product strategy.", "embedUrl" : "https://www.youtube.com/embed/wyIkXG60Wfs", "name" : "Where Good Ideas Come From in Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/wyIkXG60Wfs/hqdefault.jpg", "transcript" : "That's one thing we really emphasize here at Truefit — good ideas can come from anywhere. They can come from those who are close to the user, they can come from those who are close to the technology, and they're the ones who know what's possible. So how does the team contribute from their own expertise? Great ideas...", "uploadDate" : "2023-08-11T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Competitive research isn't about copying features — it's about finding the gaps competitors haven't filled. This short covers how a feature-gap analysis sharpens a product's actual value proposition.", "embedUrl" : "https://www.youtube.com/embed/cGnHG-WNwdM", "name" : "How Knowing Your Competition Helps Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/cGnHG-WNwdM/hqdefault.jpg", "transcript" : "We often hear, \"there are no competitors, we're on our own, where we're going there's nobody else.\" When we talk about competitors, sometimes there are direct competitors, and we reveal things that, with a little bit of investigation, show there are people offering solutions. So when we talk about competitors, they're not necessarily a competitive or competing business — there are solutions out there that are competing for your target user's attention.", "uploadDate" : "2023-07-24T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Strong UX starts with real customer understanding, not assumptions. This short covers how behavioral personas turn cold requirements into an interface that feels intuitive.", "embedUrl" : "https://www.youtube.com/embed/vNUoZktGE6M", "name" : "Getting to Know Your Customer During Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/vNUoZktGE6M/hqdefault.jpg", "transcript" : "Trying to understand what drives them, what are they hearing, what are they learning, what are they concerned about. Sometimes it's political, sometimes it's cultural, sometimes it's where their emotions come into play — depending on the nature of the product, that can be a big factor.", "uploadDate" : "2023-07-21T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "In B2B software, the person buying and the person using the product are rarely the same. This short covers how to balance what a buyer needs against what a daily user needs.", "embedUrl" : "https://www.youtube.com/embed/VPV9G1gH2VE", "name" : "End User vs. Buyer in Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/VPV9G1gH2VE/hqdefault.jpg", "transcript" : "Let's say these are the really critical outcomes you're trying to get to. Now, given our four areas of risk, let's start to unpack that: who is the customer who's going to buy this product, and ultimately, who's the end user of that product?", "uploadDate" : "2023-07-17T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Users don't buy features — they buy a better outcome for themselves. This short covers how a Jobs-to-be-Done framework clarifies exactly what a product needs to deliver.", "embedUrl" : "https://www.youtube.com/embed/ckwrkiwsy_4", "name" : "Do You Know What Your User's Goals Are?", "thumbnailUrl" : "https://img.youtube.com/vi/ckwrkiwsy_4/hqdefault.jpg", "uploadDate" : "2023-06-23T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Not every risk in a product launch carries the same weight. This short shows how to classify technical, market, and operational risk so the highest-exposure ones get addressed first.", "embedUrl" : "https://www.youtube.com/embed/Vn0J2qTpsNE", "name" : "Prioritizing Risk", "thumbnailUrl" : "https://img.youtube.com/vi/Vn0J2qTpsNE/hqdefault.jpg", "transcript" : "You also implied that not every risk is equally important. How do you deal with that? You could throw up a bunch of risks — how do you think about prioritizing risk? You're looking at assumptions — where are we making assumptions about what users want, or how easy something's going to be, or that we can build this efficiently, or that there won't be any surprises. We look along two axes: importance and evidence. How important is this assumption to the success of the product, and do we have any evidence that we're on the right track — that these assumptions are right?", "uploadDate" : "2024-08-14T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Product decisions hold up better on evidence than instinct. This short covers building a feedback loop that proves a concept is viable before a team scales around it.", "embedUrl" : "https://www.youtube.com/embed/qzfR9yF6zeU", "name" : "Gathering Evidence Through Validation", "thumbnailUrl" : "https://img.youtube.com/vi/qzfR9yF6zeU/hqdefault.jpg", "transcript" : "This is really when you start to get feedback on whether the solution we came up with in the last phase is going to solve the problem we identified. So it might be yes, and it might be no — and you need that evidence. That's the big thing.", "uploadDate" : "2023-08-21T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Managing risk isn't about avoiding it — it's about building safe ways to test it. This short covers how small, agile sprints let teams try uncertain features without risking the core product.", "embedUrl" : "https://www.youtube.com/embed/1plGRwOT-Rc", "name" : "Managing Risk in Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/1plGRwOT-Rc/hqdefault.jpg", "transcript" : "Risk is going to vary with every project. These four buckets of risk that we're talking about are present in every project, but not to the same degree — one might be more critical than another. So teams are pretty adept at calling that out and figuring out where the real priorities are. They're not always evenly distributed in neat little buckets, but time and time again, this process of identifying the critical outcomes, understanding where the risks are and what assumptions are driving that, and then getting in early to test, has proven to be instrumental in the success of our projects.", "uploadDate" : "2023-07-07T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Launching into a competitive market carries real stakes. This short summarizes the structural checks that keep a product launch on solid ground.", "embedUrl" : "https://www.youtube.com/embed/JRfO9CxDxLQ", "name" : "Understanding the Risks in Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/JRfO9CxDxLQ/hqdefault.jpg", "transcript" : "The reality is that when you're at the beginning of the product development process, you're at the point of maximum risk, because there are so many things you don't know. There are a lot of things you do know, but there are so many things you don't know.", "uploadDate" : "2023-06-19T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "This short wraps the series by recapping why a disciplined approach to risk is a real competitive advantage in software. Truefit's leadership closes out the framework covered across the Decoded series.", "embedUrl" : "https://www.youtube.com/embed/-nBEc3INIXM", "name" : "Understanding the Risks of New Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/-nBEc3INIXM/hqdefault.jpg", "transcript" : "We've spent a lot of time over the years helping to widen our clients' understanding of risk. Naturally, they're concerned about money and time, but there are other important areas to look at.", "uploadDate" : "2023-06-12T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Product-market fit isn't a fixed destination — it's a set of signals that shift over time. This short covers the leading indicators that show a product is solving an urgent, recurring problem for a defined audience.", "embedUrl" : "https://www.youtube.com/embed/s0WjnSzgqS8", "name" : "Understanding Product Market Fit", "thumbnailUrl" : "https://img.youtube.com/vi/s0WjnSzgqS8/hqdefault.jpg", "transcript" : "As we start to reduce risk, we're paying attention to some things that will make this product successful — categories of success factors we're watching as we reduce risk. There's a concept called product-market fit, and that's a common conversation. Product-market fit is: you understand the users and their needs, you know how to create value for them, and then you're executing on the solution — so you have a product that's attractive, engaging, easy to use, and does the right things. When we can prove that, and we have real engagement with the market, that's the golden sweet spot you're looking for — you've achieved product-market fit.", "uploadDate" : "2024-08-13T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Feature creep is the fastest way to miss a market window. This short covers how to narrow a feature set down to what an MVP actually needs.", "embedUrl" : "https://www.youtube.com/embed/vYjYpEnFDdw", "name" : "Finding Features to Reach Market Fit", "thumbnailUrl" : "https://img.youtube.com/vi/vYjYpEnFDdw/hqdefault.jpg", "transcript" : "This is also where things sometimes get challenging, because we work with a lot of business leaders who have big visions — they see everything that's possible with this product, very far down the road. We work with a lot of visionary people, and we love big visions. But you said minimal, right? So what's the minimal set of features that needs to be in this first release? We love big visions, but we really help people start as small as is practical to test product-market fit. The one big thing you always have to wrestle with at this stage is: how much money do you have available, what's the budget for this, and how long is it going to take to build?", "uploadDate" : "2023-08-28T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Rushing into code to hit a deadline usually creates technical debt down the line. This short covers why time spent in strategic design pays off in development speed later.", "embedUrl" : "https://www.youtube.com/embed/FHq2l_-W8Zc", "name" : "Patience Is Key to Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/FHq2l_-W8Zc/hqdefault.jpg", "transcript" : "Part of the magic of the understanding phase is using it to expose these blind spots. So giving an opportunity for discovery to do its job, and letting these other insights emerge — I'd say the one thing is: give it time.", "uploadDate" : "2023-08-02T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "In pool, the next shot is set up three moves in advance. This short uses that idea to explain why product strategy has to account for scalability and market shifts well before they happen.", "embedUrl" : "https://www.youtube.com/embed/eOVR9wHlsNc", "name" : "How Product Design Is Like Playing Pool", "thumbnailUrl" : "https://img.youtube.com/vi/eOVR9wHlsNc/hqdefault.jpg", "transcript" : "Sometimes it's like playing pool — trying to make a combination shot. We know we're trying to move the business in a certain direction, but as your product team, we can't just go out and dial up your revenue for you. We have to do it through the product. So, given the various problems we're trying to solve, what can we do in the product that will result in moving the business in the right direction?", "uploadDate" : "2023-07-28T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Founders need a clear answer to one question before scaling: is this solving a high-priority problem, or a minor one? This short covers how to test for the difference.", "embedUrl" : "https://www.youtube.com/embed/Fhs3VUOvyHM", "name" : "Is the Product You're Developing Solving the Right Problem?", "thumbnailUrl" : "https://img.youtube.com/vi/Fhs3VUOvyHM/hqdefault.jpg", "transcript" : "Is it fair to say that the discovery stage of the process is trying to make sure we're building the right thing — we're trying to make sure we're solving the right problem?", "uploadDate" : "2023-07-10T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Value is defined by the user, not the product team. This short covers how to track perceived value against actual usage so a product stays worth using.", "embedUrl" : "https://www.youtube.com/embed/AtcfFcpB2Ks", "name" : "Is Your Product Valuable to Users?", "thumbnailUrl" : "https://img.youtube.com/vi/AtcfFcpB2Ks/hqdefault.jpg", "transcript" : "One of the risks is that you have to think about the product in its context — the whole journey, the whole experience, and how it fits in. So it's not just a risk that we're building the right features, there's also a risk in whether this product is valuable in the context they're going to be using it in.", "uploadDate" : "2023-06-21T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "This is the question every product decision comes back to. This short covers how smoke tests and landing page experiments answer it before a team writes production code.", "embedUrl" : "https://www.youtube.com/embed/BwN4Uu6c40w", "name" : "Do Your Customers Want This?", "thumbnailUrl" : "https://img.youtube.com/vi/BwN4Uu6c40w/hqdefault.jpg", "transcript" : "One of the first big ones we look at is a question of value: do your customers — or, on a more complex product, do your customers — want this product?", "uploadDate" : "2023-06-14T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Waiting until launch to gather feedback is too late. This short shows how testing low-fidelity prototypes early exposes friction points before they reach production.", "embedUrl" : "https://www.youtube.com/embed/Owk54emLX_g", "name" : "What Can We Learn From Early User Testing?", "thumbnailUrl" : "https://img.youtube.com/vi/Owk54emLX_g/hqdefault.jpg", "transcript" : "You can learn two things. Certain features are going to test really highly and are in high demand — users are giving you green lights, a big thumbs up: \"if you build that, I will use it and I will pay for it.\" Super valuable, and the kind of thing you typically want to hear. But equally valuable is: \"I don't want that, I don't see any value in that,\" or, \"what can we drop off the list?\" Because the features we can either make secondary or move further back in a release plan can have a significant impact for the team. So knowing what to include and what to exclude is equally valuable.", "uploadDate" : "2023-08-23T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Software fails in the gaps between departments. This short covers how Truefit keeps design, business strategy, and engineering working from the same goal.", "embedUrl" : "https://www.youtube.com/embed/4Qh9g57Jsh0", "name" : "Product Development is a Team Sport", "thumbnailUrl" : "https://img.youtube.com/vi/4Qh9g57Jsh0/hqdefault.jpg", "transcript" : "I think one of the things we really try to emphasize is approaching this as a team sport. You have a sense of where the opportunities are — we've spent some time talking about risks, we've talked to people, and we have a sense of how we might create value for them. The key is to get your team to now start to tackle generating solutions.", "uploadDate" : "2023-08-07T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Software development is a creative problem-solving process, not just a technical one. This short covers what borrowing from design frameworks brings to rigid technical constraints.", "embedUrl" : "https://www.youtube.com/embed/gL3Mg9QBiig", "name" : "What Product Development Learns from Creative Work", "thumbnailUrl" : "https://img.youtube.com/vi/gL3Mg9QBiig/hqdefault.jpg", "transcript" : "That's a creative process, right? Because we're going wide — we're looking at lots of things, we're looking at the whole landscape, we're exploring. It's a very fun part of the process. You'll learn, and then sometimes you bump into things you didn't expect — and that's okay. We want to learn those things too.", "uploadDate" : "2023-07-31T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Shipping on time isn't the same as succeeding. This short covers the business outcomes — activation, retention, time-to-value — that define real product success.", "embedUrl" : "https://www.youtube.com/embed/rrHxgvSSkqQ", "name" : "What Success Looks Like in Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/rrHxgvSSkqQ/hqdefault.jpg", "transcript" : "We have to understand outcomes early and first, and make sure — what are the most important outcomes? There often are many that are pertinent to the project, but which are the most important, the ones we're going to be measured against? Is this going to be a success? What does success look like? If we're at the end of this project and we're all raising a glass and celebrating, what have we accomplished at that point that's going to make everybody say, \"this is a win\"?", "uploadDate" : "2023-07-14T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Every product team carries internal bias. This short covers the review practices Truefit uses to catch product flaws before they become expensive after launch.", "embedUrl" : "https://www.youtube.com/embed/Zp8-2jmnDJE", "name" : "Seeing Blindspots in Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/Zp8-2jmnDJE/hqdefault.jpg", "transcript" : "We do some neat things to really make sure we're understanding the problem — that we're illuminating any blind spots. You might understand part of it, but you're missing another key part of it, and how those two are related.", "uploadDate" : "2023-07-12T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Usage data shows what customers do; interviews show why. This short covers how to ask open-ended questions that surface the real reasons behind a buying decision.", "embedUrl" : "https://www.youtube.com/embed/2wniND7rguw", "name" : "How Interviews Help Product Development", "thumbnailUrl" : "https://img.youtube.com/vi/2wniND7rguw/hqdefault.jpg", "transcript" : "Typically, one of the first things we do is go out and set up an early, usually small, set of qualitative interviews. When we say qualitative, we're not taking measures, we're not counting numbers — we're going in and unpacking. Essentially what we want to unpack in a user interview is understanding what their current reality is like. When you're trying to do X, tell me about what it is that you do — how do you go about doing that, where do you start, where do you begin?", "uploadDate" : "2023-08-04T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Software falls behind the moment there's no system for acting on user feedback. This short covers how to filter and weigh feedback so it actually shapes the next sprint.", "embedUrl" : "https://www.youtube.com/embed/oIXl6U2W0Uc", "name" : "Why User Feedback Is Critical to Product Success", "thumbnailUrl" : "https://img.youtube.com/vi/oIXl6U2W0Uc/hqdefault.jpg", "transcript" : "Another project we're about to launch right now is in the fitness space — a really successful leader in the fitness space had done some work on an existing mobile app, brought that to us, and it wasn't going well. He wanted to take it to the next level, but as we started to really dig into it, what we realized — and what he realized — was that he wanted to solve a whole different problem. He went from one direction to a whole different product vision, which we began to validate. Now we're launching a product that looks very different from where we started in the discovery workshop. It's a great example of how things can evolve — how user interviews and competitive analysis can change the trajectory of a whole product.", "uploadDate" : "2023-07-27T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Not all feedback deserves equal weight. This short covers how to separate minor requests from the changes that actually move retention and engagement.", "embedUrl" : "https://www.youtube.com/embed/Rqy1WRg4Pvc", "name" : "User Feedback Is Critical To Success", "thumbnailUrl" : "https://img.youtube.com/vi/Rqy1WRg4Pvc/hqdefault.jpg", "transcript" : "We want to actually start to collect and get feedback from these users, and make sure — because they're not all like you. You might be a subject matter expert, but people use the product in different ways.", "uploadDate" : "2023-07-19T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Feedback only helps if a team can separate the signal from the noise. This short covers how to sort feature requests into a roadmap based on what actually drives loyalty.", "embedUrl" : "https://www.youtube.com/embed/hALwLC6YF_U", "name" : "Turning User Feedback into a Product Roadmap", "thumbnailUrl" : "https://img.youtube.com/vi/hALwLC6YF_U/hqdefault.jpg", "transcript" : "What we found was that we had a great architecture and a lot of good design patterns already in place, so the pivot wasn't as difficult as we thought — and it ramped up the value of the product. After we were able to demonstrate that, it took a little bit of time to re-engineer, but it was a critical pivot before the market release. They were able to light up a number of corporate clients they might have had a hard time getting to, and they were able to increase their expected licensing fees for the software, because there was nobody else that did what they did.", "uploadDate" : "2023-07-05T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "Great software closes the gap between engineering and the people using it. This short covers practical ways product teams stay connected to their audience.", "embedUrl" : "https://www.youtube.com/embed/e_Pu9lAxnE8", "name" : "How to Connect With Users", "thumbnailUrl" : "https://img.youtube.com/vi/e_Pu9lAxnE8/hqdefault.jpg", "transcript" : "There are things we can do to experiment early on and start to collect some evidence — yes, the answer is we can build this, or yes, people do want this or desire it, or yes, we have evidence that this is going to be easy to use.", "uploadDate" : "2023-06-28T12:00:00Z" } ``` ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "User engagement is built, not accidental. This short covers the onboarding patterns that turn a first-time user into an active one.", "embedUrl" : "https://www.youtube.com/embed/UWvz8ARtzjM", "name" : "How to Connect With and Engage Users", "thumbnailUrl" : "https://img.youtube.com/vi/UWvz8ARtzjM/hqdefault.jpg", "transcript" : "Getting that really passionate, engaged user that we're all looking for — if we can configure that area of risk out, and we can get early confirmation that we're barking up the right tree, that there is value and people want you to solve that problem, then how we solve that problem becomes important. What's the information that needs to be presented at the right time in that experience? Is it really complex, or is it easy to understand? What's the simplest way to get somebody through that process, so they don't have to do any more work than is necessary?", "uploadDate" : "2023-06-26T12:00:00Z" } ```