mParticle Sr Director of Engineering on The Role of Engineering in Building Products

It was great to hear from Sam Dozor of mParticle as he shared the role of engineering in building great products and how they see their relationship with the product team.

What is Smartype?

Are you curious about the thought that goes into building data quality and data modeling tool?

“Smartype is a data modeling and data quality tool. At mParticle, we think about data quality as really central to this requirement that businesses of all sizes have to improve their product.

Track their marketing funnels, enable their data science teams. And so all these teams have this data. They’re always looking to do something with that data. Smartype is a way to turn your plan for that data into usable code. 

To give you an example, an organization might think these are the KPIs that my business tracks. These are the funnels, these are the new features, the ways that way I want to measure this thing. And these are the associated events and maybe attributes of those events. These are the requirements of those attributes.

So, they come up with a plan, and traditionally, a lot of organizations might use Excel. They might use a Confluence doc or 100 JIRA tickets. So, what mParticle has done over the last year is build a whole data planning tool.

Why is a data plan important to a product team?

This thought process is interesting. Especially if you’re curious about the role of engineering while building a product.

“Once they’ve got this plan, we realized we need a way, or our customers need a way, to turn that plan into action. It’s really difficult for a product manager or a project manager or anybody who’s trying to collect and figure out this data strategy to then hand that off to their developers. It might be really hard for a client development team to communicate with their data science team that these are the data points we’re collecting. 

So, what Smartype does is it takes that data plan, which is essentially JSON schema, and it generates code from it. That code can be used to send data into your analytics platform to send data into mParticle. It can be used to parse data. Say you have a database or some sort of table that has all this data in it and you want to take it back out and do some playing around with it and massaging of it. You can use Smartype to deserialize and play with these objects. The whole point is that you avoid many data quality issues that lead to data quality problems.”

What went into the decision to make Smartype an open-source product?

It’s always interesting to hear how product teams make decisions when building products.

“For starters, at mParticle, we feel that we’re an extension of our customers’ infrastructure. Anyone who’s willing to include us in their infrastructure, I feel it is their right to see the code for security for auditability. They have to see exactly what the code is doing and how it’s working. 

That’s requirement one, and really all of our SDKs are open source for that reason. 

The actual way that you use Smartype, functionally speaking, we expect developers to have a fully productized version of Smartype where they go to a website and they automatically download models for their data plans or JSON schemas. However, we also expect advanced developers to clone it and manipulate it and make it as they would like to. We want developers to get in there and play with it and manipulate it.”

From an engineering perspective, what makes a great product?

We always ask this question in Product Talk, so it was fun to ask for the engineering perspective.

“Number one is, is it actually solving a problem that anybody has. Is it vaporware? Or is there an acute problem that you’re solving with it? 

Number two is, is this the developer experience? Or is the user experience? No matter who the persona is, is that appropriate? So, is it at the right level of technical? If it’s a developer product, is it very technical, but still easy to use? Is it for more of a marketing persona or less technical persona target? Is it like a no-code solution? Did you play to your market? is the user experience what it should be for that?

Have you thought through the total cost of ownership for the customer? If they implement this thing, and even if it solves great value for them, what did they have to put in? What will they have to put in moving forward to make sure it continues to get that value? If they need to constantly reach out to support or there are all sorts of defects and issues with it, maybe it’s solving a problem, but it’s also causing the customer to invest a ton of time. So ideally, it solves that problem for them at minimal or zero investment. Time investment, that is.”

What’s the role of engineers after a product launch?

This is a good reminder that the launch of a product is really just the beginning.

“It’s sort of like now almost the harder work begins. Getting feedback and making the product refined. We did all sorts of internal dogfooding, internal testing. A little bit of external testing. Now, we are doing a series of interviews with customers to see how they’re using the tool and how they’re liking the tool. We’re sort of doing like the discovery work all over again to understand what are the areas of investment to make this product really work.

Marty Cagan, of the Silicon Valley Product Group, advocates that a product is not really like GA or it’s not really production ready until you’ve got certain aspects complete. One of those aspects is really getting references from customers who love the product. So, our goal as a product team, as an engineering team, is to really advocate for the adoption of it and gather all that feedback and make it better.”

How do you work with the product team in your role as Senior Director of Engineering?

Many great PMs used to be engineers, so it’s not a surprise to see the role of engineering and their responsibilities blending so well with product.

“I’m personally a little bit of a hybrid. I’ve been with the company now for six and a half years. And have both been on the discovery and the delivery side of things over that time. One of the engineering teams I lead which is really responsible for Smartype is our Developer Tools team. That team, most of the discovery work and the real ideas come from engineering. It’s the product team’s job or sort of responsibility to filter the good. Those good ideas from the bad ideas. And to sort of give the engineers, myself, and others a reality check. So, it’s a give and take.

mParticle is split up into a series of squads. Each with different mandates. Product teams, you could say. We are paired with the product manager, who is thinking through what is the go-to-market for the continuous, new deployment of Smartype. How are our adoption metrics looking? All the time, ultimately, how is this affecting and mParticle’s leads? We have daily stand-ups. So, the product team and the engineering team at mParticle are really like one team. We really work very tightly together. It’s not like a separate wall or anything like that.”

Are there ways, from your experience, that work better in terms of the two teams working together even though it’s kind of blended at mParticle?

The role of engineering has a place is a company, just as each other team does. Knowing how it all fits together is the key to unity.

“I think each team needs some air cover. To feel ownership is the most important thing. I think the product team really needs to feel ownership over the adoption and feedback. And the why we’re building this thing.

As an engineering team, we’re happy to leave that to them and to really figure out the why. Why do we spend all this time? Point us in the right direction. We love running the in the sprints. The product team sort of like points us in the right direction where we want to go and engineers they love coming up with ideas and being creative and come up with tricky solutions to hard problems. Most of the engineering team is perfectly happy for the product team to take their ideas and sprinkle water on them and flush them out. Take them from ideas to actual strategies that fit within a narrative for the mandate of the team.”

Products That Count is proud to partner with mParticle to provide incredible insight from their product-focused team. To learn more about mParticle, you can explore their platform demo for free here.