#hyperpublic

We had a saying on my former team at comScore: there's data, data, (pause) and then there's data.

As you've likely too frequently read, there is more data being created and collected today than ever before. New data streams are being generated by modern businesses, governments, hobbyists, devices, etc… It's often reported as the panacea to solve problems and a go to way to unlock new opportunities. The abundance of new data is correlated, if not caused by, the massive reduction in storage cost on both an absolute and relative basis. Moreover, storage and access can dynamically change with both planned and unplanned usage. Early stage technology companies often have a majority of their expenditure allotted to salary (labor with a capital L) rather than hardware (capital a capital K). Large companies can have major data related costs in hardware, licenses, and people though hopefully have reasons to invest given market success. For both large and small companies, there is affordable options to capture and store all the data within reach even prior to a known way to make sense of it or make money from it. Storing everything you can is treated like a no brainer.

Fine, granted, so what can we do with it? Well, there's data, data, (pause) and then there's data. Spoiler, there is a fourth level of data too. 

Data level 1: Existence

What to capture?

How to implement measurement and storage?

Data level 2: Availability

How to access?

How to visualize?

Data level 3: Trust

How to make decisions based on data?

How to become a data driven culture?

Data level 4: Decision

How to automate decision making?

How to create data driven products?

I've heard some people map this to information -> data -> insight -> knowledge. This is bite sized, vague, and devoid of practical implication; it's a I-know-it-when-I-see-it  segmentation. Here is an attempt to walkthrough how to think about specific decisions you'll encounter as you try to infuse data into your company's operation, product, and psyche.

This will focus on broader operational decisions and motivation rather than specific technical systems. It also largely ignores the specific engineering challenges related to long term storage and serving data at web scale.

In the technology sector, it seems that only the upper echelon of large technology companies and promising, engineering focused upstarts can attract and afford the diverse technical, operational, and scientific talent necessary to answer the above questions.

I've ignore many related topics so just take this for what you will. If you're passionate and can lead me to ways to make this easier, please send me a note. I think data and its applications will be the raw materials of the next great businesses and for all of our advancements, we're still clunking our way through the basics.

____

The first level of data is merely creating and capturing it correctly. You've chosen to log something, you've implemented the tracking, you've piped it to homegrown (lots of work) or third party analytic systems, and you've verified it's both consistent and complete. None of these tasks are trivial; they often require multiple people, iteration, debugging, etc… In the web space, you can go a long way by instrumenting client side code (what the user actually sees in browser) using excellent off the shelf tools like Mixpanel, KissMetrix, Google Analytics, ChartBeat, etc… This approach still requires front end modifications, testing, diligence to maintain, up front time for learning their systems, and some medium term lock in to their policies. You still need to do validation and common sense sniff testing to ensure you're getting the results you'd expect, especially if you do anything even slightly custom. 

Measuring server side code or other backend systems (the fun part where you application performs) is often performed by logging- your code writes out some flat lines of text or formatted key-value pairs (JSON, XML, etc.). Most business executives think this type of logging should come "for free" when systems are built but there is often complex work to create and capture relevant data.

This requires a level of precision not typically found in day to day non-engineering life. Even highly skilled analysts, big data distributed algorithm gurus, and Ph.D. data scientists are rarely equipped to design what to log and how to log it. It's a bit of science and art. There are tradeoffs for performance, data size, correctness, etc… Many of these tradeoffs require thinking through how the data will be queried which means predicting usage by others (not an easy task). Engineers may approach this from a code coverage perspective: "Are we logging errors? Is code executing in a performant way? How early can we tell there is a functional problem? Are the machines operating normally?" While critical and necessary, it is not sufficient. We need to also measure if the system is achieving its goal: "Are the current outputs or behaviors correct and/or normal? Are users using the system in successful way? Is the data being generate useful?" These questions require much more thoughtful definition and are inherently subjective. You need to interpret how code impacts people, businesses, and other systems. You can successful log errors, keep the machines healthy, maintain your uptime, beat your SLA requirements, and still produce garbage data? Do you want to know that ASAP or when people start complaining downstream... 

Concrete example: At Hyperpublic, we indexed lots of data about local businesses, places, and venues from publicly available sources. We were building, and the team continues to build at Groupon, scalable systems for collecting this data, normalizing it, and determining the most likely accurate information. Let's imagine we're interested in the physical address of the business: it's not enough to instrument application code to alert on errors, we need to monitor how well the system is determining a place's likely street address. Yeah, the machines are on and the processes are running, but is it producing good results? Should people using this data be happy?

One helpful way to get started is to pick one, and only one, measure of a data stream's validity. Picking one metric that means something to the team can be the driving motivation to follow through the project from beginning to end (Kissmetrics blog has a nice detailed post on some ideas per business type). It's best, though not required, if this measure can (1) be computed independently from other systems, (2) operate on one record at a time, (3) be stateless, (4) performed computationally trivially, (5) improves the accuracy of the test over time, and (6) have tangible meaning to non-engineers and non-stats people: i.e. normal people. This means that your metrics can be performed on streams of incoming data, can be distributed over multiple threads, process, and/or machines, doesn't impact application performance, creates new understanding of expected results over time, and can be described to everyone in the company. If it fails any of these needs, you may have to overcome more complex engineering and insight challenges but that's where the creativity and fun comes in.

Designing these metrics is the fascinating intersection of engineering, statistics, and business insight. Are you looking for a massive abrupt shift, a slow change over time, or an individual data anomaly? Being aware of how you'll evaluate the summary statistics will impact your choice in how you measure and design the system.

That's a lot of work, and we're still at data level one. If your data isn't well structured, you're in a whole other boat.

Data level two. 

Ok. So now you've chosen what to measure, next up is convincing the team, or yourself, that it's important to integrate the tracking. This can become a major endeavor that can rabbit hole its way into a long term project with no clear early wins. Do not bite off too much at first. Pick one thing, get it working, get it on a graph, get that graph on the wall, and high five. Yes, you will make some short term decisions that will likely require rewriting down the line. Yes, you will build some short term systems that are single purpose, don't scale to new sources, don't allow for arbitrary analytic access, but this is the only way I know how to get anything done. I don't always do a good job with it because it can be so damn fun to plan and draw data flow diagrams (seriously one of my favorite things to do). Resist the urge. Use the open source tools, steal the front-end view from your neighbor, and just get that metric on the wall. You'll feel better.

Data level 3. If you've made it this far, the data is flowing… Can you query it? Can you, with confidence, make decisions based on it? Can you ask someone else at the company what the state of that monitor is? Is it in your daily workflow? Does everyone trust it? Can the CEO read it? Is there any ambiguity? This is the softer, and harder, side of data. It always have caveats, coverage issues, and is susceptible to misinterpretation. 

Your instinct might be to create wikis though they have very low likelihood of improving the situation. This step does not come overnight. You need to create a trusting relationship between the data and you, your team, and your company. Like all good relationships it takes time, attention, frequent interaction, retrospection, and occasionally intervention. Once you reach a healthy level of trust, data will become invaluable. Everyone will want access, teams that didn't see the value earlier will want to participate, and data will have a voice when decisions are made. Now you might need to rebuild your systems to handle the scale of new use cases, uptime requirements, data volume, storage needs, privacy requirements, access controls, retention policies, ad hoc vs. production schedules, concurrency, asynchronous collection, better viewing tools, alarms, sessionization, long term reporting, back up, etc… This just became a real asset and requires commitment.

Data level 4. This is the stage that's talked about the most-- data as a feature. It's what powers product recommendations, search engines, news feeds, ad targeting, etc… There is statistical, testing, and production engineering focused on servicing data needs in this area but we'll leave that for another post. This is the promised land but is a ways off from where most companies are…

Most companies’ internal operations have the same goals-- get things done, clearly communicate what's going on, and remove anything blocking employee success. As a company grows from infancy to first engineer to small team to (gasp!) larger company, the mechanism for this communication must evolve. There are innumerable paths to formalize this important interaction. There are books, blogs, tips and tricks as well as "certified" trainers, masters, and other ring leaders dedicated to teaching and selling you on how to ensure this communication exists. Google for "daily stand up" (490M results), "status meeting" (280M), "agile" (69M), or "scrum" (21M) and you'll quickly dive into the rabbit hole. I’ve recently worked at a large company and an early stage start up: at comScore, I managed a three person team within 1000+ person company and at Hyperpublic I was one of ten people. We've tried many of the above techniques and have found some strategies that have worked for us.

At a high level, we settled on one meeting each morning at 10:30am where we stand in a circle for at maximum 15 minutes. After 15 minutes, we halt and return to our regularly scheduled days. We don’t wait for people to show up; at 10:30am we start, and at latest 10:45am we stop without exception. Each person answers three questions:

What did you do yesterday?

What are you going to do today?

What's blocking you?

It took us a while to reach this equilibrium and we didn't stick to it 100% but it became our norm after a while. We'll need to try something else now as we transition to Groupon post acquisition.

Two person start up: If you're just two people, this communication may be a constant flow of information back and forth throughout the day. Enforcing the strictness of any of the formal strategies might be overkill or ruin the magic of the early days. I still suggest some dedicated, regimented time where you discuss day to day progress without devolving into strategy sessions or more detailed review. First engineer: Once you bring on your first engineer, he or she is going to (1) want clarity into the daily operations of the company, (2) have many early blockers, and (3) enjoy showing off progress. The stand up is a safe place for him or her to report how things are going and for you to quickly hear any issues that arise. There is wonderful freedom and opportunity being the first engineer, but it can also be scary and isolating. A daily stand up with the full team is a great way for he or she to see the direction of the company, feel pride in today’s work, and ask any questions. One large team: Once you've grown to a handful of engineers, some junior and some senior, and maybe have hired a designer or marketing person. The team can quickly feel scattered and the room no longer speaks the same language. It's critical to bring everyone around the same proverbial table. The full team can understand what each member does and it gives a everyone a larger sense of purpose and team direction when you see the many facets of the company. Multiple teams: Now that you're even larger, you have multiple projects and, abruptly, people have gone from being your buddy to being your "stakeholder." What we're doing is now a “priority” and soon becoming an “initiative.” This is the stage where good intentions of how to ensure schedules and communication are clear go off the rails in reality. You might hire a project manager, but that person can quickly be sidelined to a mere record keeper or a schedule holder. He or she will make demands on people’s time and often not have the background to garner confidence from the team. I suggest growing very slowly in terms of formal mechanisms for project management like sprints, hours, or story points and try to have it occur organically. See if one of the current team members is willing (or excited) to take on this additional responsibility before bringing in a standard PM.

What I've learned: Keep it simple:

For the stand up just stick to: what did you do yesterday, what are you doing today, what's blocking you. Refrain from diving any deeper.

Don't take notes and don't worry about following up on the specific things people mentioned from the day before.

It’s not worth forcing people to participate; you and the team have to want this. It won't work if you're being dragged to the meeting, always late to an early stand up, or ridiculing the process.

Just try one aspect of a more formalized technique.

The stickler:

Organic, bottoms up approach is best to new ideas but you needs one person as the leader. This may be the VP of engineering but could also be any team member. Some have this role change owners over time.

At Hyperpublic, I suggested that we try daily stand ups and found consensus that it would be worthwhile. Then our head of engineering successfully led the sessions. That worked well.

The leader ensures the meeting happens on time, ends on time, and encourages people throughout.

If a teammate reports he or she has an issue that is preventing progress, it's the leader's responsibility to solve that blocker and report back next time.

The champion:

The champion might introduce new aspects to the meeting, gauge interest amongst the crowd, and fine tune things that seem off.

It's a coach role; a mix of inspiration and guidance. Make sure to back away to merely a participant as soon as possible and let the leader execute the meetings.

Don't use technology:

This meeting is a special time where there are no computers; it's about people talking to people.

Don't be tempted to takes notes during it. If the list of blockers becomes long (you likely have a larger problem), just simply write them on a whiteboard.

Actually stand:

At first, it may be annoying to enforce, but respect the standing part of a stand up.

Standing for 10 to 15 minutes signals that this meeting is short term and is different from other parts of the day. You’re not going to review code or debate marketing copy while standing in a circle.

It sounds like overkill but try to not lean against anything. This is a gateway drug to sitting.

Include executives:

Including executives and other senior leaders gives the team confidence in management.

The team will appreciate insight to the executives’ day to day work.

Executives get to quickly hear a snapshot of what everyone is doing.

Have fun:

Add something unique and out of the box. It could some quick some silly chant, a joke, or a clap. We had a clap at the end of each meeting and, while it took a while, our rhythm and timing got a lot better!

New employees will be excited to learn about your insight joke and it’s fun if other teams get to see you do it. It's the same as in middle school when you saw the rival sports team have that cool pregame ritual.

At minimum, you will likely get the following:

The whole team in at work by some time every morning.

A healthy, non-competitive peer pressure to generate substantial progress every day. Who wants to be the person struggling to manufacture a status update?

Management signals to employees that they care about day to day progress and stresses.

A collective, non-technology tainted team gathering.

Cross discipline discussion and quick view into broad operations for all employees.

Unveil management’s day to day inter workings.

Decrease the time from existence of a problem to a solution.

Something fun to do everyday.

Knowing when to skimp and when to splurge is an important trait for entrepreneurs. Entrepreneurs come from different backgrounds, often technology or business, and may be inexperienced in some of the softer skill decisions. Non business, non financing, non technology decisions are the ones that often craft the company's culture, its mood, its soul. It's an area I think a lot about and try to test different practices, see how others are attempting it, and now, well, writing about it. Having not written about much during my time at Hyperpublic, I’ll attempt to walk back through some of the things I’ve learned and been exposed to.

Some context: When I was first approached by the founders of Hyperpublic, I was a weary and with some good reason. Though well funded and led by an excellent duo, it was a young company, and like many others, still trying to define it's product: narrow consumer application, broad consumer service, or developer data platform. After a few phone calls, it seemed reasonable to trek up from DC to meet them in person. 

Easy train up the coast, express subway from Penn Station to 14th Street, and a short walk through the beautiful open streets near the Meatpacking district, I was already excited by the possibly of working there. The hallways seemed like they were perpetually under construction (turned out to be true) which inspired that jaunt up the stairs energy that I assume people feel on Christmas. The office is a massive space with 18 foot tall loft style ceilings, rounded pillars scattered throughout the room, and windows!-- many large windows in front of each desk. Massively large panels of prints of a map of New York were hung on the walls. Each person had his own large desk facing a window, separate common table for snacks, another for lunch and meetings, and another in a secluded, more relaxed area with a couch and larger comfy chairs. It wasn't fancy, it wasn't glitzy, it just had it's own feeling of simplicity, scale, and serenity.

It was like, woah… these guys must have something going on. At minimum, they have excellent taste. The space could easily fit 15-20 comfortably and 30+ by most NYC square foot per person standards. At the time, I think, they had only 4 people and recently had hired the latest person. The space inspired aspirations and confidence even though I'm not sure the company knew which path to bet on.

It's a miss match. They could have been working from an apartment, a subleased space shared with another company, in a worse neighborhood, it could have been smaller, etc... 

Having a space that people want to come and work in is worth splurging on. Our space was a recruitment tool, a motivator, and our home. Here is a top of mind list of aspects to think about when choosing your next space or maybe sprucing up your current.

Common space: Make a special area that’s outside of day to day work. Is there room for people to relax together, have an impromptu meeting, or host a medium sized group? It doesn't need to be fancy: we had a donated old couch, a few larger chairs surrounding a low glass table, and what would generously be described as an orange rug.

Lunch space: Eating together is important for all families. For the most part, we ate together and almost always back at the office. We had one large glass table and could easily roll our desk chairs over to create a new space, a lunch space where conversation could flow between personal and company topics. A separate space signaled that this time period was different. Eating at your desk would seem out of place. When we had our tenth guy join and were all seated around the table, it felt good. We had to squeeze but having a dedicated space made it even more special. It gives you a benchmark to measure growth. An auto-reminisce.

Mix use walls: The wall space can be anything. With our tall white walls and large (but light) art, we could quickly switch from office setting to presentation mode for internal meetings or external events. It served as a movie night and XBOX screen as well. We didn't have a conference room (some negatives here) so quickly firing up the projector, taking down the art pieces can change the room's mood and the people in it.

Transportation: It goes without saying that being near major subway stops is critical. Half of our team lived in Manhattan and the other in Brooklyn. Being off the ACE and the L removed any commute hesitation from candidates. That's an easy one. What resonated to me was also that we were not right off the subway line. Maybe I read too much into these things or push my own ideas on to a bland reality, but it felt good to walk a few blocks from the closest stop than just pop up into your building. I sang a different tune on rainy days but that natural energy felt good before work. Walking in NYC also shows you people you don't interact with during the day. If I entered the the office immediately from the subway, I'd miss seeing the ways most people use technology and interact with the world. Of course, I was also getting a biased view given it's the Meatpacking district.

Art: Explaining that you do local data aggregation is a little easier and more fun while standing in front of a beautiful print of Manhattan. It gave our work context; like an unspoken mantra behind us. 

Light: Some days we never needed to flip the light switch. The office beamed with light, too much in the afternoon sometimes (some engineers shifted their machines to avoid glare). The light gave the office warmth. Don’t cage yourself in.

Color: Having some color, at least for me, speaks that creativity is the norm. We had matching hanging red lights and exposed red painted water pipes. It doesn't need to be fancy, just get some color. Paint the place together if needed.

Restaurant options: Be able to walk to multiple food options. Eating great food from non chains sparked excitement and can demonstrate what excellence looks like in other areas of life.

Hosting: Open your space to the world. We hosting some SkillShare events, a few small meet ups, and any visiting out-of-towners looking for a desk and internet. It encourages employees to tell their friends about the company and to welcome others. 

Private space: Employees should be able to change between public and private setting. We didn't have a different space for this at Hyperpublic and it caused some friction. We had one open room and no private space which meant personal and some business calls we relegated to the hallways. A small conference or huddle room would have solve this. 

I think this kind of detail is important. Together, these aspects create your environment. Companies compete on talent and then need to compete on execution. When you have the opportunity to invest in something that fuels both of these critical advantages, splurge. Check out the pride that Kickstarter has in their office. Peruse officesnapshots.com or the stream of office pictures on Instagram. It doesn’t need to be MTV cribs, but make it reflect your values and presentable.

Here is a round up of some of the Hyperpublic acquisition press coverage over the last few days. I really enjoyed the analysis from Matt Turck. We appreciate him hosting us for his first NYC Business of Data meet up.

Techcrunch: http://techcrunch.com/2012/02/17/groupon-acquires-nyc-based-startup-hyperpublic/

NYTimes: http://bits.blogs.nytimes.com/2012/02/17/groupon-nabs-hyperpublic-a-local-data-start-up/

VentureBeat: http://venturebeat.com/2012/02/17/groupon-buys-hyperpublic/

WSJ: http://online.wsj.com/article/SB10001424052970204880404577229772298409702.html

BetaBeat: http://www.betabeat.com/2012/02/20/they-did-it-all-for-the-data-groupon-buys-hyperpublic/

Matt Turck: http://bigdatanerds.wordpress.com/2012/02/20/hyperpublic-acquired-by-groupon/

CBSNews: http://www.cbsnews.com/8301-505124_162-57381353/will-groupon-let-app-developers-integrate-deals/ 

Fox Business News: http://www.foxbusiness.com/technology/2012/02/20/groupon-buys-start-up-hyperpublic/

StreetFight: http://streetfightmag.com/2012/02/21/groupon-hyperpublic-better-targeting-and-better-data-for-merchants

Inc: http://wire.inc.com/2012/02/21/groupon-grabs-data-start-up/

It's been a very exciting six months between leaving comScore to join Hyperpublic and our recent acquisition to Groupon. I am so proud of the team and happy for our founders Jordan Cooper and Doug Petkanics. Just over two years ago, they started the company and quickly morphed their original idea into the local data platform that attracted me to help them in this venture. The team is amazing and I am honored work with them. They're relentlessly smart, well rounded, and wonderful to spend time with.

In between, I fell off putting my ideas to paper and subjecting them to any public criticism and evaluation-- not to mention the self afflicted is-this-good-enough when you hit the publish button. Moving to NYC, ensuring the people close to me felt settled in, and getting into the start up work groove took top priority rather than writing but I suspect there is a better balance. So, I write my second post about how I am going to write more. I'm a todo list guy (Asana FTW) and this is now near the top of the list.

Changing from medium-large public company to small start up and back to large public company in such a short period of time has pushed my boundaries, made me face my own shortcomings, and energized me to find the best people and ideas I can and work hard to make them successful. I intend to share what I can about all of this.

After all the drama around Groupon's IPO, it seems like the company has remained relatively quiet and there hasn't been too much excitement around the stock. Since its IPO, GRPN has gone as high as $31.14 per share and as low as $14.85, and now the share price has settled at $20.26. And as I've mentioned here previously, I don't really consider Groupon to be a tech company and didn't think their IPO should (would is a different story) affect the IPO market for tech companies after them. Additionally, Groupon's main competitor, LivingSocial, hasn't been too active either. Both companies just seem to be humming along and relatively content to be settled in to the market that they essentially created. That was up until the last week and a half or so. In that time span, Groupon has announced three acquisitions: Adku, Hyperpublic, and Kima Labs. While all three startups will contribute to Groupon in different ways, they all will bolster the daily deal site's technology, an area that has been severely lacking.

On February 6, Groupon announced the acquisition of Adku, an e-commerce data company. Adku's technology optimizes a person's shopping experience by providing product suggestions on sites like Amazon, eBay, and Zappos. Groupon has long been criticized for not providing targeted daily deals (bikini waxes and pole dancing classes in Boston aren't exactly what I'm looking for), and this acquisition should go a long way towards helping Groupon and its merchants send the right deals to the right people. Meanwhile, just yesterday Groupon announced the acquisitions of Hyperpublic and Kima Labs. Hyperpublic is a particularly interesting acquisition as it is really a pure technology / data play. The NYC-based startup creates databases of local info and makes them available to developers for free and will certainly help Groupon figure out how to target customers by location, an essential feature for services like Groupon Now. Lastly, the acquisition of Kima Labs should better enable Groupon's mobile payments capabilities.