Menu
StackRox Co-Founder and Unusual GP Wei Lien Dang shares best practices for stress-testing early product assumptions on the journey to product-market fit.
Once you’ve qualified five to 10 design partners and they’ve signed an MNDA, you’re ready to dive into building your minimum viable product (MVP) with them.
At StackRox — the cloud-native security company I co-founded and sold to Red Hat — we worked with six design partners who did more than just provide feedback about the product we were building. Our design partners validated key assumptions, forced us to rethink priorities, and helped refine our product roadmap during the pre–product-market fit phase. Their critical insights refined the initial use cases we decided to support and ultimately helped shape StackRox to become the leading Kubernetes-native security platform for cloud-native applications.
Once we’d defined our initial ideal customer profile (ICP), we spent roughly a month making sure that we qualified the right design partners, who were primarily mid-market enterprises running Kubernetes.
Based on my experience at StackRox and working for other companies like AWS and Splunk, I’ve learned that successful design partnerships strike a balance between clarity of vision and plenty of room for change based on feedback. Here are some tips for creating a win-win situation for your company and your design partners.
At the start of each engagement, ensure there is agreement on project goals and how you will collaborate. Set expectations for how your discussions may or may not impact product priorities and delivery.
Your goal as a founder is to validate technical insights and to stress-test early product assumptions. The design partners’ role is to influence and shape the product so that it solves an immediate pain point for them. This is key to why you need to qualify design partners to ensure they have a real problem you can help them solve now.
Focus on shaping your product to meet real market need by balancing:
For example, Macroscope, an Unusual portfolio company, is actively working with several design partners to build their MVP. Macroscope’s two foundational goals are to clearly understand the dynamic between developers and finance leaders and to build a tool that developers want to use.
And as you sync with your design partners, make sure you’re aligning the priorities of their business to your solution.
As my partner (and Unusual Ventures Co-founder) John Vrionis covers in What are design partners?, your product doesn’t need to be 100% figured out when you start working with your design partners.
Think of your product as solving 80% of a design partners’ need around a problem. Design partners are early adopters who help you solve the remaining 20% of a critical problem so that it addresses a much larger customer base. They should be able to clearly articulate their problem and provide you with the understanding needed to develop a solution.
Effective meetings with design partners are more than casual conversations. Whether virtual or in-person, regular live check-ins are critical. Before you meet, make sure your design partners have actually deployed your product.
We recommend meeting every other week with your design partners. At StackRox, my co-founders and I met bi-weekly for at least 30 minutes with our advocates and relevant technical stakeholders at each of our design partners. Our advocates were generally DevOps engineers who were driving adoption of Kubernetes within their organizations and looking to secure the container images they were building. Other stakeholders included infrastructure and security engineers who wanted to understand how they would operate our product within their environment and how it would meet their organization’s security requirements. We chose a bi-weekly cadence to align with our engineering sprints so that we could synthesize learnings from our meetings and then quickly incorporate them into our product iterations — even if it meant prototyping or building proof-of-concepts of features.
In addition to consistent meetings, establish open channels for design partners to provide feedback or to bubble up issues. Communicate asynchronously with Slack or email to answer questions and stay on top of design partners’ comments.
<Encouragefeedback><Encouragefeedback>
Constructive, honest feedback is one of the most important ingredients in the design partnership recipe. What do your users need to see in order to feel comfortable with your product? Their answers will shape your MVP.
Honest feedback is driven more by how you solicit feedback than by saying you want honest feedback.
If you can, avoid doing detailed walkthroughs or demos of new features. Instead present what you’ve built with as little fanfare as possible and ask your design partners to react. Reactions to wireframes for a new feature that are not influenced by a walkthrough provide the most valuable feedback about how well that feature hits the mark.
Pre-GA is not the time for people-pleasing or confirming your own point of view. Set up interactions in which you are most likely to get honest reactions and listen to what your advocates are actually telling you — remember, they want you to succeed! Oftentimes, it’s easier for someone unbiased “outside the room” to provide substantive feedback about your product.
“In a previous company I worked for, conversations were difficult when it came to critical feedback,” says Brian Regan, co-founder & head of product of Macroscope. “Now when I see other founders going through a demo, I realize who’s trying to get someone to agree with them instead of generating honest feedback.”
Companies want to work with vendors that provide helpful service and support in addition to a great solution, which is why high-quality communication matters.
Remember that design partners are dedicating their time to deploying and using it and making a bet on your product to solve their problem. They want to be confident that your company will be a long-term partner to them, so do all you can to convey your professionalism and attention to building the best product possible.
During the active communication phase of design partnerships, your goal shouldn’t be to sell your product. As my former colleague Corinne Moran, a sales GTM expert, puts it, a founder’s goal is to learn from their design partners who resemble their future desired customers. “Give your design partners the floor and don’t interrupt until they’re done talking,” she advises.
Additionally, she recommends asking follow-up questions to encourage design partners to further explain their thoughts — sometimes they are agreeing with your point of view rather than expressing their own challenges.
OR
If you’re unsure what follow-up questions to ask, be willing to follow customers down any thought path. Try asking “why?” As in, “You said that you’ve previously tried to solve this problem internally but it was not successful. Why are you reprioritizing this initiative today?
If you’re worried that you’re asking too many questions, rest assured it’s part of the process. “Once you get down to something, we watch customers figure things out in real time. It’s enlightening for them,” says Jim Treinen, Macroscope’s co-founder and CEO. “They may not have realized what their biggest problems are until you ask them to dig deeper.”
Don’t rely on memory alone; document the details of your calls and communications — then look for common themes. For example, if you hear “this feature is more important than this feature” consistently from design partners, you’ve likely got a key takeaway to inform your priorities. From there, think about how to use the feedback to shape the MVP.
The Macroscope team created a database to track details of every call; they track feature requests and tag the design partners that have brought them up. “It’s a lot of work but helpful when you want to revisit feedback and are trying to remember which customer experienced a particular situation,” Brian says. “We’re in the info gathering phase — we want to make sure we can reference all of this early feedback for years to come and as our team expands.”
I highly recommend recording conversations and capturing key takeaways about design partners’ feedback. As your company grows, it will become important to share context behind why you’ve made certain decisions with future employees.
We recommend Grain to record calls, Notion to capture notes, and Airtable, Trello, or Asana to manage projects.
A month into your design partnerships, stop to reflect on what you’ve learned. Do all your design partners still want to solve the same problem?
Do not treat design partners and their feedback in isolation. We encourage sharing learnings across the design partner organizations. For example, when you meet with one design partner, you could say, “We heard X feedback from this other company — what do you think about that?” or “We’re thinking about prioritizing this feature based on requests from other companies; would it be relevant to you?” In sharing a summary of feedback across organizations, you might tap into something that an individual design partner hadn’t thought about but could find intriguing.
Have you ever met colleagues who nod their heads and smile as you’re talking with them about a project or idea? While that cue might seem like validation of your ideas, it might not be the case. Don’t assume that head-nodding and compliments from prospective design partners means they’ll actually deploy or buy your product later on. In fact, you also can’t assume that someone who says they’ll buy your product means they’ll actually use it. The key takeaway here: genuine validation only comes from actual usage of your product during a design partnership. Pull up your product’s UI and watch users interact with it or have them go through the key workflows live to surface what’s working well and what isn’t.
True: Founders need to validate their product vision with design partners, but to be clear, what you decide to build should not solely be based on what design partners tell you. Design partners can help you refine and fill in some of the details, but they’re not meant to tell you what your product vision should be.
At StackRox, we wanted to build a new platform that addressed the new security challenges created by running cloud-native applications. Many organizations couldn’t yet clearly articulate these problems or what they needed, and we found it beneficial to give them a reference to help them voice their thinking. In our case, we used design wireframes to mock up proposed features and workflows that our advocates could then use to provide feedback.
Since they’re receiving critical feedback during the prototype phase, the Macroscope team mocks up the UI in live code and gets direct feedback from design partners, allowing them to iterate quickly. Instead of debating for hours about how features “should work,” they build sparsely defined features that look like wireframes and say to their partners, “What would you put here?”
Be prepared to reevaluate your key assumptions during your design partnerships. In the case of StackRox, we initially targeted advocates who were part of centralized security teams at large enterprises. Our early engagements helped us realize that we should have instead been working with DevOps teams who were leading efforts to build, run, and secure their containerized applications in line with “shift left” and DevSecOps trends. We made this mistake because our founding team was focused on talking with people in our networks — essentially, very security-focused people. Once we stepped outside of the networks we knew and engaged with DevOps engineers, we had our pivotal a-ha! moment and course-corrected.
Macroscope’s initial product vision has shifted a bit during the design partnership process — as it often should. “People didn’t quite get our initial vision, but you cannot cram your vision down people’s throats,” Jim says of investing time into narrowing down and tweaking their vision based on input from design partners. “But when we showed the refined design, the lights clicked on. Our partners went from not giving precise answers to our questions to saying, ‘Yes! That’s what we need.’ That’s when I knew the process was working.”
Yes, ideally your design partners will become your early customers, but that doesn’t mean your job is to always say “yes.”
It’s all too easy for founders to feel pressure to do whatever a potential customer wants, but that doesn’t always get you, or your product, to where it needs to be. It’s important to establish credibility, trust, and rapport with your advocates so that you can appropriately push back at times.
Generally, most companies are pretty understanding if you’re able to provide thoughtful rationale to explain why it doesn’t make sense to prioritize something at a given time.
Design partnerships, when enabled thoughtfully, can accelerate your company’s path to product-market fit.
