Hey everyone! I’m back from BlackHat, vacation, business travel and the first day of school and sort of ready for life to return to normal, or at least as normal as things get during a global pandemic. The last two months have been INSANELY busy and honestly, I’ve just not had the time to write anything. In any event, I’ve been writing this series about 6-8 months behind where we are and I realize I really should catch you up a bit more, for a few reasons. The first of course, is that I remember everything a lot more clearly right after it happened. Secondly, we are actually going to have a lot more to say in the next few months. Our product has made amazing progress and we will have a big announcement on October 12th!
That’s not to say it was easy. Not at all. Over the last few months we had some serious technical challenges we had to overcome. After all, we are tackling the hardest problem in data science: data. More on that in my next installment.
Anyway, In my last installment of SILS, we had just hired the beginnings of our web-app team. In an effort to get this blog caught up to present day a bit quicker, I’m going to do a bit of fast forwarding. Around this time, I had started to update my linkedIn profile to reflect that I was no longer working at JP Morgan and I think I may have even written a blog post or two. Regardless, something happened and caused one of the smartest people I’ve ever had the pleasure of working with to contact me, whose name is Curtis Lambert.
Curtis and I knew each other from having worked together for a number of years at Booz Allen on various projects. Without a doubt Curtis is one of THE sharpest people I’ve ever worked with. I’ll let him tell his whole story should he choose to, but his story is really inspiring. Anyway, Curtis contacts me out of the blue and asks me what I’m up to. We have a zoom call a few days later, and I pretty much gave him a job offer on the spot.
Once Curtis was on board, he and I had something else in common: we knew that the government is full of talented contractors who don’t really like working as contractors. So, we did what anyone else in our position would do… recruited them. Thankfully we didn’t recruit enough from our former employer to get a cease and desist letter, but we were able to put together a great technical team of really talented folks.
The Biggest Challenge: Prioritizing
I thought I’d pause the history here, and just talk a little about the biggest challenges of early stage startup and that is prioritizing. You have to be absolutely ruthless with prioritization. RUTHLESS. As the technical co-founder, and the guy with the product vision this is exceptionally difficult. You have this vision of an amazing product that gets 200mpg, solves world hunger, ends global warming, and establishes world peace. Yet, the first versions of your product don’t quite match up to your vision. The first versions…well, they likely won’t do any of those things.
If you’re launching a startup, you are doing something unique, something risky and something that hasn’t been done before. So guess what? It’s HARD! On top of that, you have limited resources, so as the founder, you have to map out how to implement your vision in a logical way so that you can achieve product-market fit as quickly as possible.
For me, I can say without hesitation, that this is the hardest thing for me. We’ve had a few of what I call “ruthless prioritization” sessions, where you have to go through your feature list and decide what’s going in the next deployment and in what order. My problem is that I want it all… :-). Geospatial query builder, yup! Continuous scroll, absolutely! Drag and drop column rearrangement, of course!! You get the idea.
I wish I had some magic formula for how we prioritize, but I don’t. What I do is look at the list and ask the question: “Which of these features would prevent a user from using the tool?” Once I have that list, I really try to be ruthless about it. Once that’s done, you can start asking: “Which of these features will enable us to do something new?” etc. There are various methods, like the MOSCOW (Must have, Should have, COuld have, Won’t have), and these can be helpful for release planning.
But it isn’t always that easy. For example, we had been discussing implementing continuous scroll for our table view. This is a really nice feature because it allows you to eliminate all the pagination controls in the UI and is much more intuitive for the user. However, it is more complex to engineer. So as the product person what do you do? Now, you need some sort of pagination, so even not implementing continuous scroll has a cost. Do you implement regular pagination and put continuous scroll in the backlog? Do you put your foot down and say “no, this is vital feature and we’re doing it!” What would you do? I’ll tell you what we did in the next installment!