AMA: Crossbeam VP of Product, Lindsey DeFalco on Building 0-1 Products

The two biggest things to ask are: "would they?" and "could they?". This is both a question of strategy and tactics - of both you, and the competitor. My first startup was a directly competitive product with multiple established players in the space, so this was a topic from day one. My second startup is a "first of its kind" product with no direct competitors initially, but we have asked ourselves this same question a few times about large, tangential incumbents as we've built our company. The best way to do this exercise is via SWOT analysis: for you and your competitors. Map out: * where you are uniquely positioned to play and win (via your opportunities and strengths) * where your competitor is uniquely positioned to respond (via their opportunities and strengths) * where you are vulnerable to competitive threats (via your weaknesses and threats) * where your competitor is vulnerable to you (via their weaknesses and threats) Usually, large competitors don't have the agility to duplicate what you're building at anywhere near the speed that you're able to move as a startup: don't underestimate the time it takes large companies to make decisions, alter strategy, and execute on that strategy. They usually work in annual cycles for large strategic initiatives, and quarterly cycles for execution. Most large companies don't have the process in place to pivot outside of those timeframes without it being incredibly disruptive: take advantage of that. That being said, it is also important to consider how aggressively you are going to market and where you decide to play - it's not wise to go poke a bear (a large competitor) directly, but smarter to build up a strategy that will sneak you in through a side or back door into the market. This also brings up the importance of how you get to PMF and how quickly you are able to get to PMF. If you do it slowly, and very publicly, it will give competition the time to say "hey, maybe we should do something about that". Think carefully about how you market yourself when you are very early: do you private beta, get MVP validation, then go to market more broadly? Or do you "launch" more publicly earlier? These strategies will depend on the competitive landscape and what you strategy is on entering the market. There is a fantastic book on this topic called Playing to Win: How Strategy Really Works that I highly recommend.

Ah, brainstorming: it sounds so simple, but it can be so hard to do well. I've tried many different approaches over the years, and have found different ones successful depending on the company size, co-location of folks, etc. I'll go over my favorites, but first I want to touch on a few important pre-requisites to the brainstorming itself. Attendees * Representatives from teams that will be working on the problem: in startups, this is likely almost everyone on product, design, engineering. At larger companies, it may be a PM, designer, and tech lead. * The people with the most domain expertise: PMs should always be experts on the domain, but you may be selling to sales people and have actual sales people who do the job daily in house - bring them in! * Customer success: so much valuable information lives with this team. I could write a whole post on ensuring you act on CS feedback strategically, and not blindly, but that's for another time! * Any leadership that cares about the topic and is excited by brainstorming. I'll touch on the latter in just a second, but don't bring leadership in who just wants a download of the result - it will drag down the mood and you can get them aligned after the exercise, separately. The most important thing is that attendees are excited about brainstorming! I've held many a session with very apathetic, not-into-brainstorming teams, and it's tough. There are ways to mitigate this with how you run the exercise, which I'll gett to, but some people just don't love sitting in the ideation space, and that's okay, but recognize it, and choose your attendees accordingly. Prep This is really important and often overlooked. Make sure everyone comes in with the right expectations of the session, access to any read-ahead material, and the right attitude about what to expect in the session: be specific with the agenda! Ensure everyone is aligned on the problem. There's nothing more distracting to brainstorming than live hashing out the problem you're trying to solve. If you need another pre-work session to get everyone aligned on the problem being solved, do that! But go into the brainstorm with a clear problem space definition. Brainstorming Exercises * Whiteboard. My absolute favorite way to brainstorm is in a room with a whiteboard. Hands down. Even now, in the fully remote world, we will travel in and do live, in person sessions for big brainstorming sessions. This isn't always possible, but when it is - it's a great time and highly effective. * Give everyone a marker. Encourage everyone to hop up and draw things, even if it's just words and boxes. * This is more unstructured and works well for very small companies where everyone is incredibly aligned on the problem, strategy, users, etc. * Figjam. In this remote world, getting together in person isn't always possible. Enter figjam! We use a template that supports ideation via sticky creation, theming, and voting. * More specifically, for the UX portion, we have had a lot of success with the Crazy 8's exercise. It is a great way to force folks to draw boxes, a la whiteboard. A few other notes: * Never underestimate the value of an incredible product designer. Their presence and ability to translate ideas into beautiful UX makes brainstorming more successful and more enjoyable. * I encourage my PMs to get into Figma and be familiar enough with it to move things around when brainstorming and solution-ing. Designers shouldn't be precious over Figma and PMs shouldn't be afraid to go in there and draw ugly arrows and boxes to visually express their ideas. (But PMs, please, make a copy off to the side and don't mess with design's final deliverables!) After all of this: test, test, test, Talk to customers, watch them use your prototypes, let them tell you what works, what doesn't work, rinse and repeat. There is a fantastic book on this called Just Enough Research. It's a quick read and an incredible playbook for doing "just enough" research.

#1: Trust. You have to earn it. It's all fun and games when there is "nothing to lose" and you're a small scrappy startup. But once you have paying customers, usage targets to hit, churn numbers to report on, and revenue numbers to hit, it starts to feel harder to launch. I've been through this transition as a startup turns into a real company and have found having the following things in place really helps: 1. Trust from the rest of the org that you are THE expert on your customers. I was fortunate to attend a workshop with Marty Cagan (SVPG), whose content - blogs and books- I can't recommend highly enough, and he said "Until you convince the company that you know more about the customers than anyone else, you won’t be taken seriously. And you will have no credibility with executives." This trust is the baseline for you to be able to take risks and for leadership to be willing to "trust the process". 2. Culture of experimentation: next up, frame your "embarrassing" launches as "experiments" (which, I would argue, every launch is an experiment) and report out on them as experiments. Make failure a thing: not a good thing, not a bad thing, but just a thing that you learn from. Have specific outcome targets and metrics and don't stop until you hit them. If you don't hit them with that first, embarrassing launch, then you iterate. 3. Process supporting iteration: this is related to the first two bullets because you can't truly experiment without being able to iterate, and you won't gain the trust of the company without them seeing you quickly iterate. I've done this well, and I've done this poorly. 1. When I did it poorly: I was doing "feature based" roadmaps and work back in the day. This meant you "finished" a feature and moved onto the next. It was almost impossible to iterate on learnings from the feature because the team had moved on, AND they weren't measuring the success of the feature in terms of outcomes, but rather general performance. Don't do this! Marty Cagan has a fantastic article on this. 2. When I've done it better: align your teams (and PMs) around outcomes. Tell them, very clearly, "launching this isn't a success, getting to the desired outcome is a success, and that may take a few iterations". Get your team really comfortable with creating MVPs that you can learn from, and then quickly iterate. And talk about it! Post in Slack: "we launched this, no one liked it, we changed it and now people like it", "we got feedback this wasn't working, we just shipped a change", "we watched user sessions and looked at the data and made this tweak", etc. TL;DR; gain trust from the company leadership by demonstrating your deep customer knowledge and your ability to quickly respond to feedback and iterate on MVPs. Frame success around outcomes, not features.

This is heavily dependent on the type of product you are building, but you can get very far with high fidelity designs and manually "hacking" things together. I worked at a company where we "generated" (hand created) an analytics report for a customer (who was actually paying us) once a month. It took an insane amount of time to create (20+ hours) but the feedback on both how to sell, and how to build our product from that experience were invaluable. Start light: with high-fidelity designs and clickable prototypes. Once you have consistent signal from your ideal user persona saying that they would use the product if it existed, then get to work on a POC (proof of concept) only. Don't fully trust your customers just yet - you still need to prove that they will actually use it. I believe all early initial engineering work should be treated as POC work. Piece together what you need to in order to get the validation that people will actually use it. At this point, you are building to learn, not to last. Once you are starting to see usage and actual traction (and in parallel are having success in the market on positioning and selling), that's when the decisions around how to invest in engineering will come in. Again, this is highly dependent on the type of product you are building, but the biggest trap people fall into is focusing on scale before seeing any success. Be scrappy at first, scale later. And build to learn.