Sahil Jain’s Post

Build the low effort, mid value feature or high effort, high value feature? Paul Wicker and I were just discussing what use case is the right one to really focus on at this early stage. In over 100 feedback calls, we’ve had numerous PMs give us feedback about a particular use case (Feature #1) , which is undoubtedly the highest value problem/use case we could tackle, but its big, meaty, a lot of nuance, and is a high effort buildout. The use case we started with (Feature #2) is a lot clearer, simple, relatively easy to build, but has probably a 3/10 value. There are great arguments to be made on both sides, and using spectrum thinking, probably a way to straddle a bit of both or find a compromise [CAUTION]. On one hand, Feature #2, gets something to market quicker, and you’d imagine the many small details, the scaffolding, around that feature, will be extensible to anything built after. This route gets you to feedback quickest. Feature #1, of course, builds far more intrigue. Unfortunately, it isn’t so simple. Feature #2 may get something to market quicker, but if the value of it is so low, will anyone care? Will anyone care enough to take a demo? To try it? To stick with it in hopes you will build more valuable stuff soon? Feature #1 may be more valuable, in its few word description, but getting it to that full realization of value is far more complex, and nuanced. There have to be some thresholds. For example, maybe you build Feature #1 to lets say a 5/10 quality implementation, so not the whole realization, but enough to be mid-quality, high value. This lowers the effort, starts you on the journey of the harder, more valuable use case. But there are still a lot of unknowns with Feature #1. And anyone who has built and shipped real revenue driving product knows it's /never/ as simple as it may seem. There is no right answer here. And compromises are dangerous, especially for early stage startups. Can we really do 2 things at once, super well? Some of my founder friends would go high value, higher effort first. There is wisdom there, too. We decided the following: 1. Stick to the quicker to potential usage/feedback, and build the easier Feature #2 2. Allude to Feature #1, so we can mention it on demos, show it in the UI, even if not very functional -- this allows us to open the convo on the high value use case, define it further 3. Time box a reasonable investment and cycles in the easier Feature #2, and if in lets say 1 quarter, it is just too low value to have anyone care, it's not the end of the world, tackle Feature #2, or some Feature #3 will emerge because we at least got At Bats for feedback. I am super thankful Paul and I can have these hard convos. One of the big benefits of having worked together for over 10 years.