NextView
Tamiz Ahmed is a former product manager at Bleacher Report, where he helped build the successful app for sports fans, Team Stream, prior to the company’s nine-figure sale to Turner. Ahmed is a former Googler and the current founder of Nani. Below, he shares product management lessons from his time at BR.
NVV: Let’s begin at the beginning: Why did Bleacher Report even want to launch this app? Where did Team Stream fit in BR’s already broad content ecosystem? What about the sports media landscape overall?
The reason Team Stream was launched was because we wanted to build something that could bring to life a sports fan’s entire sports consumption experience,focusing on the teams and topics you cared about most. We felt that, without the app, you had all these different news sources but no single places to consume them all, whether you’re a New York sports fan living in San Francisco like me who just wants to keep up with your teams, or you’re a diehard in your hometown who follows every single professional and amateur blogger. The goal was to give you a customized, local feel around your team.
There were two core things we focused on: First, lots of national topics were being covered by ESPN, so people already went to them for general sports news. So we focused on getting more specific by team, specifically focusing on popular teams that didn’t get as much national attention. Second, we thought about curation. Bleacher Report and Team Stream were always built on the idea of curating information and the best sports stories from across the web. Our advantage was that we were source agnostic. Whereas ESPN only promotes ESPN content in their app and other channels, we could include the big, national outlets plus local coverage, social media discussion, and more.
Bleacher Report’s Team Stream app
NVV: What were the first steps taken to turn this into the mainstream success it is today?
One of the biggest ways the app evolved from day one was from a design point of view. We had launched early Android and iPhone versions and tried to get coverage, and while they did okay initially, the app wasn’t customized to either platform. So that’s one thing we struggled with early — we wanted to deliver the best, most customized experience, but we were straddling both versions and neither felt as customized as they could be. So that was an early tradeoff the team made as a startup within a startup. We followed the data: The iPhone app was initially twice the users of the Android app, so we started focusing more on that to design a more customized product.
If there’s any lesson there, it’s that you want to lean into what’s working early and keep going in that direction. Our users were telling us something, so rather than try to make the lesser success work, we doubled down on iOS to start. When I joined the team (coming from Google) we started focusing on giving the Android app a more authentic Android feel.
NVV: Even though BR was a later-stage startup at that point, you mentioned being that proverbial “startup within a startup.” What other tough choices besides iOS versus Android did you make to gain early traction?
The entire product team on the app was just me and my boss at the time. While we had BR engineers building the APIs that power the app and designers creating the look and feel, we didn’t have any mobile app developers in-house to put the pieces together and make a beautiful user experience. So we worked with an external development shop to help build the app front end across all platforms.
Then more day to day, we had to do a little bit of everything. We were our own customer support team, for example, which I think is huge for product teams. It’s the best way to learn and build the right thing.
Every day started with a certain period of reading user emails and looking at crash reports. Those aren’t necessarily the sexiest things, but we were getting incredibly valuable feedback. An app can crash for a number of reasons, whether due to a user’s device or something with our actual app. You always miss something when you’re running a million miles an hour at a startup, so every morning, we would commit to checking crash reports and filtering through user emails and high alert bugs.
In terms of iterations, we always had a launch coming for mobile and tried to release a new version every three weeks. Part of that was due to new features, part was due to advertising campaigns for brands being natively integrated into the app, and part was due to the necessary fixes we found from our morning sessions.
NVV: What key metrics did you track to make sure you were heading in the right direction?
In addition to the standard daily and monthly active users tracking, pages per session and time in the app were both huge metrics for us. We would always try to do things that made it easier for people to stay in the actual app to fulfill all their needs as a sports fan. With that goal in mind, all feature development got easier. That’s why we built in a game score integration, for example — so people wouldn’t need to leave to go find scores. At first, they’d get discussion and analysis in our app but then have to leave to visit the BR site or even a competitor to get the actual scores. Because we valued pages per session and time spent in the app, the scores feature not only helped our audience get what they needed, it helped us keep gaining better traction towards our goals.
NVV: You went from a giant, global product organization at Google to a two-person product team inside the smaller product organization at BR. What new lessons did you learn working in a smaller, scrappier way?
Involve customers in the process. I can’t say that loudly enough. For Team Stream, we’d use NPS surveys, which would also lead to feature requests. To determine if they were valid requests, we’d create an MVP — or more likely some mockups of a feature — then bring in some customers and do focus group-type meetings.
One thing that worked well that I’d encourage others try is to bring in a very targeted demographic. At BR, that could have meant a high school or teen sports fan who typically loved BR site content. They were a subset of our existing audience, but sometimes, they’d talk about apps that we didn’t use ourselves and in ways we weren’t familiar with. It was great to get their perspective. But in general, startups need to be great about having direct customer conversations.
Another thing I learned being a PM at a startup that also thought a lot about scale and big audience was to make your product “idiot-proof.” Now, I’m not saying our users were idiots at all. Don’t misunderstand. But you want to avoid the simple customer requests and emails as best as you can. If a canned response can answer something over email to a user, and you find yourself sending that response a lot, that’s a product problem. You need to make that simple thing actually simple to do.
So for me, it’s not about user intelligence, it’s that I wanted to focus on making an action as simple as possible. If I thought an icon was cute to use to identify a button or an action in the app, then the questions needs to be: Would that make sense to most users? Sometimes, we’d literally walk around the office and ask people if it would make sense or what it meant to them.
All of this is because, as a mobile user, if you don’t know exactly what you’re doing in an app you’ve downloaded, there are millions of other apps you can go use instead of ours. If they can’t figure out what to do in your app right away, you’re done. You only get one shot once they download.
NVV: How did you balance the need to make incremental improvements and reactionary decisions with the need to think longer term about the app?
The biggest thing is to always take a step back. Along with the need to review bug reports and crash reports is the need for a tool and a process to effectively prioritize needs based on users, advertisers, internal politics, and all of that. Some of those may not apply to seed-stage startups — maybe politics becomes more of an issue at larger organizations — but the need to prioritize is always important. What are your essentials before launch? What are your nice-to-haves that you’ll save for later or skip entirely? What tools or processes do you need to help with major priorities?
[Editor’s note: Tamiz says he used PivotalTracker and Crashlytics (now owned by Twitter) while at BR.]
Team Stream is now established as an app, but even today, they still need to ask if they’re doing something that would affect a large percentage of their users. That’s not to say you can’t do the stuff for smaller groups, especially if it has a big impact for those small groups. My point is really that product managers can’t let those smaller things define your entire job, because they really could if you let them. You will always notice the little things that could be better since you feel a sense of pride and are constantly examining your product. But you need to prioritize your list.
For us at BR, we wanted to have that mentality to keep shipping. So, yes, that meant a lot of the things we’d add to our lists would get pushed down, but that’s honestly the system working well. If something keeps getting pushed down in favor of other things, that’s a sign it’s not worth doing and doesn’t help enough users.
You can follow Tamiz on Twitter @tamiz. At the time of this writing, Nani is in pre-launch mode.