Foreword
This is the first issue of my first newsletter, and I need every bit of feedback I can get. Too long, to generic, not technical enough, too dry, or anything specific you’d like to see tackled. Let me know and don’t mince your words… I promise to take everything into and improve as make this newsletter as worthy as I can.
Failing to plan is planning to fail.
Whether you measure success in tangible ROI or mission impact, the biggest threat to your project is the same: confusion on what to build to hit your goals when tech is not your forte.
Today, we’re going to walk through how to get that clarity.
Polar Stork Flock, Leipzig - Summer 2019
Hi there,
The struggle to build lasting, effective software is universal. Whether you measure success in tangible ROI or mission impact, the biggest threat to your project is the same: confusion on what to build to hit your goals.
We’ve worked with 100+ founders in the last 12 years and nine times out of ten their great ideas can quickly go from great to painful, not by complex engineering, but by the Idea Gap: the distance between your original vision and your team's fuzzy execution.
When a technical partner executes a vague request without challenging it or suggesting a better way, they are simply deferring a huge, expensive clarity problem of the best way to build a solution until past launch day.
Today, I’m going to walk you through getting clarity on what you need and how to work with your development team to find the best way to get that built, so you can build the right thing from the beginning and have it scale for years to come.
Let’s go!
What to expect
Takeaway For Founders: The hidden cost of skipping discovery and how it destroys your MVP.
Takeaway For Nonprofits: Why shipping features without a clear "why" compromises your mission and bandwidth.
Behind the Scenes: What the Storkers were up to this week.
The most expensive line of code is the one you didn't need to write.
Clarity gives direction to engineering. Without clarity, engineering is just “typing code”. A developer can build a solution in a lot of directions. But they need the short term and long term clarity to know what to build now and what that will look like and function like in the future to know the best direction.
You need to have both the vision (direction) and the knowhow (technical skills to go in that direction).
After years of building platforms, we've learned a truth: technology problems are almost always problems with clarity. They just look like they are only about engineering.
Your Product Isn't Stuck Because of Code: It's Stuck Because of Confusion
What does Technical Debt Look Like?
You see the tax in things like:
Wasted Hours: Your team builds features that users don't need or want.
Technical Debt: Quick fixes and poor choices are made just to keep up with changing plans.
Lost Opportunity: Your product gets bogged down in complexity and misses its chance to succeed.
Burnout: Your team feels like they are always running around, fixing small issues instead of the main problem.
It’s getting what you think you want and not what you or your users actually need.
How Confusion Gets Coded In
Some founders hire a development team hoping for a company that will simply do everything they ask or even reading their mind. This may seem fast at first, but it is risky. Such a partner is afraid to question your ideas, ask "why," or say no when an idea is flawed.
Instead of fixing the gap between what you think might work and what will actually work, they just put it off. But the problem doesn't go away. It gets written into the code, and it becomes much more expensive to fix later.
Why Your MVP Might Fail (It's Not the Code)
Relative cost of fixing defects (source: https://www.researchgate.net/)
For founders focused on moving fast, skipping a discovery phase seems like it saves time. It doesn't.
The discovery phase involves:
Identifying the players
Understanding the problem
Landscape analysis
Option exploration
Choosing the simplest path
This is the main reason MVPs (Minimum Viable Products) fail.
The goal of an MVP is not to just “make it work”.
It’s to understand the users, to know where to build out the product further, to find PMF (Product-Market Fit).
To build a Simple, Loveable, Product. Not just a widget that works.
And based on where you’re coming from (VC, Bootstrapped, NGO with a funding cliff), you’re going to have different objectives, timelines, and end goals.
The best development agencies are ones who look at the problem and work with you to find the best way to build a product that solves it. They don’t start with feature sets, they start with listening to (current and future) users.
That’s why when you ask us for a new feature, we first ask the critical "Why?":
Why is this feature needed, right now?
Do your users truly think it's right, or is it just something you want?
Does this feature fit with your main goal, or is it a feature for feature’s sake?
This is not to slow you down. We just want to make sure every dollar you spend gives users something they will actually use. We save you money by stopping bad ideas from being built.
Confusion is a Drain on Your Mission Bandwidth
For nonprofits, the importance of clarity is measured in human impact and how well you operate. Not being clear costs you lost impact and tired staff.
When technology is built without a clear idea of what your people, volunteers, or staff need, the system’s problems force your team to waste time on extra work.
Imagine a team spending 10 hours a week fixing donor spreadsheets because the system wasn’t made for how they actually work. This extra work is not just slow; it directly hurts your ability to reach your goals.
Many groups come to us with a solution, like "We need a new website."
Our process is to spend more time on planning with groups like yours. We help you separate:
What you truly want to achieve (like more volunteers or community engagement).
From the expensive and complicated system you think you need.
We might find that a clearer sign-up process and simple, automatic emails are much better and will last longer than a full rebuild. This open talk makes sure the technology is simple and lasts. It helps your audience the most without becoming a lot of extra work to manage. We focus on solutions that are real and will last, so you can have the greatest possible impact with limited money.
Build Fast, Build Well
Whether you want to sell a lot of products quickly or make a big difference in the world, being very clear is the fastest way to succeed. This means working with a partner who will question your ideas and ask the hard questions. We make sure every line of code has a real purpose.
Don't let ambiguous requirements become your next product's biggest bug.
To get a clearer plan before you hire a tech partner, follow these three steps:
Figure Out Your "Why"
First, you need to know what problem you're solving and why it's important. Don't just list features. Think about your customer's journey and why they would use your product.
For example, for SMBs, instead of saying, "I want a new app," say, "We need a tool that cuts customer service calls by 30% this year."
For non-profits, you could say, "We need a new system to get 15% more volunteers to stay with us.”
This is where you and your design partner can see where there are holes in the discovery done before the proposal and what needs to be done for the product to be as close to perfect as possible.
Map the User's Journey(s)
Now, put yourself in your user's shoes. Draw out every step they'll take from when they first hear about your product to when they achieve their goal:
SMBs, draw out the customer's path from hearing about your service to making a purchase and becoming a loyal customer. And all of the smaller journeys that make that up, from creating an account to using a feature to completing a payment.
Nonprofits, decide if you’re covering the whole journey or just parts. should map the journey a person takes from learning about your cause to becoming a volunteer or donor and seeing their impact. [the reason for your existence.] What parts are required for the type of app. What parts are completely unique for the problem you were setup to solve
Write a project brief
Don’t put in technical details
Tell me what you know, that I (the developer) don’t.
You don’t want to restrict the possible solutions.
You want to clearly define the problem, your goal, and what function should your users be able to do.
Then we go back
Who is on the project from your team? A data scientist or the CMO? What’s their background, their involvement, what are their goals for solving this problem?
What are your limitations, in terms of timeline, budget, scope, integrations and compatibility with existing systems, hardware, and tech stack.
All of this is true whether you’re an SMB or a Non-profit.
These are the pieces of clarity that get you to the best product possible, on time, and in budget.
News from the Nest (Sarah, Engineering team)
After a few months working on the Bridging Voice website, focusing on web accessibility, Sarah took on an amazing challenge - build an accessibility auditing tool that give actionable feedback adapted for each of Leadership, Managers and developers.
She called it Access Lens.
A first experience owning the roadmap, building primarily using AI Studio, and putting together an awesome product based on real life experience and learnings. It was refreshing to see an engineer in the driving seat - curious to be in the client shoes for once, and determined to build something impactful.
Useful Resources: As you define what you need from your product
Summary: This article shows how the term MVP has been misused. It explains that founders often launch a product that only has a few features, instead of launching a full, good starting version for the user. It gives clear steps to make sure your first product is truly valuable and ready to grow.
Summary: This brief gives non-profits a simple plan to match their tech tools to their team's skills. It points out that even great technology will fail if the organization does not have the right people and steps in place to use and manage it well.
Summary: The article argues that you shouldn't just build a "Minimum Viable Product" (MVP), which is often incomplete and bad for customers. Instead, you should make a product that is Simple, Lovable, and Complete (SLC). This means it's small, finished, and people actually love it, helping you build a happy user base.
