SDO 011 - Operations Behind Emerging Data Products - Shabnam Mokhtarani
What are your thoughts on being an early employee at a startup?
I have some exciting news! I'm soon starting a dream job as one of the first employees at a data infrastructure startup— I plan to share more details soon, but expect a lot more data engineering content from me! Though I recorded this interview in November, my interview with Shabnam was the exact advice I needed for my upcoming new role. She drops gem after gem of knowledge detailing what the early days were like for her at a pre-product startup and what led her to success thus far.
One theme stands clear above the rest when you are in an early startup: you must go out and talk to your potential users— as many as possible. I learned this in my entrepreneurship programs at Stanford, I learned this the hard way when my former co-founders and I interviewed at Y Combinator, and I'm learning again from Shabnam's interview. When you have a pitch deck and minimum viable product (emphasis on minimum), user interviews are the competitive advantage you can create that is 1) hard for others to replicate and 2) set the foundation for your product-market-fit journey.
Hear from Shabnam Mokhtarani, COO at Featureform:
You don't need "data" in your title to have a massive impact on the data space, and Shabnam is an excellent example. I met her at a data meetup in San Francisco through Simba, the founder of Featureform, and was highly impressed by her deep level of understanding of the pain points experienced by data professionals. The more I learned about her tech career, the more I became impressed, and I knew I had to interview her for my newsletter. Thus, I'm incredibly excited for you to read her insights on navigating an early startup and her ability to combine deep technical skills with intense customer obsession. I hope you learn as much as I did from our talk!
Thanks for reading Scaling DataOps! Subscribe for insights from data leaders every week.
You are COO of Featureform, but you also have a technical background as a software engineer. How do you balance both sides while leading an early-stage startup?
Shabnam: "Yeah that's a great question. The way that question's phrased, it makes me feel like they should be in conflict and I actually don't feel like they are. I, in fact, I think it makes me stronger in my role. Featureform is a very technical product and it's built for a technical crowd, data scientists and ML engineers, and this fact is something we can't escape.
It colors the approach to our marketing, our sales, recruitment, and obviously the product. And I feel like my background as a software engineer made it much easier to understand the problem that we're trying to solve and how to be empathetic to our end users. I know the experience of implementing a new tool and getting confused by poor design decisions or being frustrated by documentation that's hard to navigate or incomplete. And that experience has stayed with me for better or worse.
I always think about how someone will be using our product and what they'll go and tell their friends. And so it plays a huge part in how we operate and the things that we prioritize, both in the short term and the long term.
I think on a practical level, it's also been really helpful to have an engineering background. Especially in early stage startup, you have to be really versatile. Like in the early days when I had first joined and it was just Simba and I, there were times where I had to write some code or build tutorials or work on docs. We have an amazing dev team now that handles all of that which I'm very, very happy about. But being able to troubleshoot an issue or walk through a technical problem with either an end user or a customer has been really, really helpful."
You played an integral role in having your company's open source ML software reach over 1000 GitHub stars. What advice would you give to other open source projects trying to grow within a fractured market?
Shabnam: "I guess one of the biggest takeaways and a good place to start is that you really can't underestimate the importance of talking to potential users, especially when you're pre-product. Before we had launched the open source feature store, I would talk to as many folks as I possibly could in data science and machine learning to get a better understanding of how they work, why they do the things they do, why they choose certain tools, what keeps them up at night. And I feel like this gave us a couple benefits.
First, it was a great way to build my network and yeah, you're not going to meet every person that would give you a GitHub star. That obviously doesn't scale, but it's a great way to build relationships and make friends in the community. And maybe one day they'll mention you to a colleague or share a LinkedIn post. Maybe they'll be in the market for your product one day and they'll remember you.
The second benefit that I can summarize is in these meetings the feedback would give me a lot of insight into what our target audience finds interesting and what problems they're facing. And that really helped us drive one of our biggest levers in marketing and just building an open source community-- and that would be content. Cause it gave me a good baseline of like what people's expectations are and what they're looking for. And that being said, we chose to focus on long form content that was really high quality.
We tried working with content marketers and I think for our stage it's really important that the content you write come from a place of, not to sound cheesy, but real passion, I guess. And that's something that's really hard to outsource because no one's going to care about the problems that your potential customers or end users are gonna face more than you. And it's also a really good way to build trust through the content that you create. For us, a lot of folks ended up using our content as a reference. And that actually made them, I think, more likely to visit the repo or also maybe use the product.
The other area that I think was really helpful for us was instead of starting and trying to build a community like a Slack community, right off the bat ourselves, we took advantage of existing communities. And that could be on Slack, it could be on Discord, Reddit is really great for this. And we use those spaces to share updates, get feedback, find relevant meetups, find conferences. And this was really helpful for us because A) when you're pre-product, what are you gonna put in your community? There are already a lot of great communities for folks in data science and ML and it's something that you can't hack. You can't force people to come to a community and be engaged.
So I think it was a really good use of our time to focus on external communities. And instead of trying to build something internally, it's kind of like a, "if you build it, they will come." And by it, I mean the product. So once we did release the product, we started to get folks joining our community, asking questions filing bug reports, looking for tutorials. And I think that was really, really helpful in building open source traction.
The other thing that I think that was really helpful for us was focusing on experimentation. So that could be with the type of content that you put out. Like we launched a podcast. We figured that's another good way of kind of building some brand awareness, getting folks to warm up to Featureform without feeling like they're being sold to.
And it gave them an opportunity to get to know us, to get to know Simba. But when you're going into experimentation, I think you need to do that within reason. Building trust is a really important part of building an open source community. So, you know, going to crazy with ads or spamming people, those can be mistakes that turn people off.
So, yeah, I think making sure that you're iterating, you're trying new things is really, really important in kind of figuring out what works for you. I think also when you're early stage, folks don't really wanna build out maybe like a full analytic dashboard or anything like that, but it is important to measure what you're doing.
And that could be with UTM campaigns, it could be like Google Analytics. Something that was really, really helpful for us was I set up an integration between Slack and GitHub with Zapier. So pretty much every time someone would star us, I would get a ping in a channel. And it was a really great way of like getting feedback in real time cuz I could see we did launch this blog post, or we launched on Hacker News. We got a bunch of stars.
It's not as easy to measure in the sense of it won't be present in a dashboard or something like that. But it will give you a feeling early on when I think it's hard to fully measure things off of what works well and what doesn't, and you can see what's working well in real time."
Your technical background initially didn't include data, yet you were able to quickly get up to speed on the ML space to best serve your customers. What advice would you give leaders in similar situations who are trying to help their org become more data driven?
Shabnam: "I can definitely speak to that. When I joined Featureform, I mean my background was a nice mix of software engineering and then I did operations at Slack. And part of that job was a bit technical, like programming access control systems, building security servers.
But it was definitely when I switched to engineering that I got my technical chops I feel like. So I was really interested in AI, ML, I knew that was an area that every business will be affected by. So I had the interest there and when I met Simba, I just felt like, okay, this is a great opportunity to learn on the job.
I'm definitely the type of person that does better through doing than just reading, being able to think critically and put things into practice. So the first thing I did I remember was Andrew Ng has a bunch of really good courses on Coursera. He has one on, like unsupervised learning, supervised learning. I started there just to get a sense like, okay, what do data scientists and machine learning engineers do? And then from there I went on Kaggle and just started playing around with introductory datasets. So I remember I did like the Iris dataset, I did The Titanic dataset, I did a fraud detection dataset. And that gave me enough information to kind of understand what are the processes, what is the workflow that a data scientist actually relies on on a day to day. That only took me so far though, because Kaggle competitions and real world machine learning workflows are very different.
There's quite a gap there. So I had mentioned before the kind of discovery calls that I would do with folks before we had launched the open source feature store. Part of my goal there was also just to learn what does machine learning look like in a real job outside of a project.
And I thought that was the most helpful in kind of painting the whole picture for me, especially the data engineering side. Featureform is a product for data scientists, but a lot of times the folks that implement a feature store are oftentimes a machine learning engineer. It could be a data engineer. So kind of understanding the workings under the hood of how you collect data, clean it, transform it into a feature, get it into production with a model or train a model during experimentation. All of that was really important.
I think the other thing that was helpful for me was going into communities, like I would go read r/datascience or r/machinelearning every week. Which is kind of fun, right? You never really think like, oh, being on Reddit is a good way of helping in your job. But I would get really honest takes from people. Sometimes I would ask questions as well, like, "What are your biggest pain points? For example when you're using notebooks and sharing them across your org," it's a great way of getting real time feedback from people. And on a medium like Reddit, people are a lot of times anonymous, so they will give you really frank feedback and responses.
And I also joined MLOps community. I joined Data Talks Club Discord servers. Through there I would find meetups and just go talk to people. I feel like I've said that a lot but I would not underestimate just going and getting the info from like the horse's mouth, I guess.
You know, you can read blog posts. There's a ton of great podcasts. There's a lot of courses online, things like that. But finding people that are willing to have an honest conversation with you, it's invaluable and I think when you're doing that, it's also really important to come from a sincere place.
When I would reach out to folks, I would let them know I'm not go here to talk about what we're doing at Featureform. I'm not even gonna really mention it unless they are really curious about it. The sincerity there will go a long way in kind of getting folks to share what they really think, what their work is like because they know that you're not trying to sell to them."
Shabnam Mokhtarani is the COO at Featureform. Feel free to connect with her on LinkedIn to learn more about her work at Featureform and consider giving them a star on GitHub.
What are others saying in the DataOps space?
Five Feature Store Usage Patterns: From Single Data Scientists to Enterprises | FeatureForm
What: A blog detailing the usage patterns of feature stores at various levels of scale, from single data scientists to enterprises.
Why: Shabnam detailed in her interview the importance of high-quality long-form content for growing users, and this recent blog serves as an excellent example.
Who: You are looking for an example of content that you can use to grow the trust between your product and your target audience.
Steve Blank Customer Discovery
What: Steve Blank is an accomplished entrepreneur, documenting many of his learnings on his website, with many emphasizing the importance of user interviews.
Why: Applying to the Stanford Lean Launchpad class (ENGR 245), taught by Steve Blank, was my first taste of being a founder and understanding the importance of user interviews; you had to complete 10 to apply.
Who: You are either a founder or an aspiring entrepreneur looking to test a business idea.
Read This Before Joining as Employee 1 to 20 at a Startup
What: Article from First Round Review providing real-life experiences of being an early employee at a startup and tips to help you succeed.
Why: Though exhilarating, the ambiguity and lack of structure (and often lack money) in an early startup can be hard to navigate— so learn from those who have successfully scaled their startup.
Who: You are like me, joining an early-stage startup soon.