What is Differential Privacy?

One of the notable concepts to emerge from Apple’s World Wide Developers Conference in San Francisco this year, has been the notion of differential privacy. As Wired puts it Differential Privacy is the “…statistical science of trying to learn as much as possible about a group while learning as little as possible about any individual in it.”

Introduction

One of the notable concepts to emerge from Apple’s World Wide Developers Conference in San Francisco this year, has been the notion of differential privacy. As Wired puts it Differential Privacy is the “…statistical science of trying to learn as much as possible about a group while learning as little as possible about any individual in it.” 

Let’s say you wanted to count how many of your online friends were dogs, while respecting the maxim that, on the Internet, nobody should know you’re a dog. To do this, you could ask each friend to answer the question “Are you a dog?” in the following way. Each friend should flip a coin in secret, and answer the question truthfully if the coin came up heads; but, if the coin came up tails, that friend should always say “Yes” regardless.

Then you could get a good estimate of the true count from the greater-than-half fraction of your friends that answered “Yes”. However, you still wouldn’t know which of your friends was a dog: each answer “Yes” would most likely be due to that friend’s coin flip coming up tails. (source: Google)

The premise of differential privacy lies in that the reports are indistiguishable, the random coin flips have no unique identifiers, yet the aggregation of reports allow us to share common results shared by many users. With companies like Facebook and Google constantly receiving flack for compromising user privacy in lieu of the value of selling customer insights, and user-targeted advertising, Apple are more-or-less perceived as the beacon when it comes to championing user privacy. Differential Privacy is Apple’s answer as the industry embeds itself more and more in mobile and wearable renaissance, especially with location-capable devices making privacy-invasiveness more frequent. 

Whilst Apple have never had a great interest in user data, compared to the others, as it slowly and publicly revealed its intentions to work with big data, to improve Siri’s contextual knowledge, instead of going the Google-way, it has instead opted for the sliding-scale modelof differential privacy. 

“People have entrusted us with their most personal information. We owe them nothing less than the best protections that we can possibly provide.” (Tim Cook, White House Cybersecurity Summit, ’15).

As consumers become more security and privacy-conscious, in light of the NSA and other global revelations, it has never been more imperative that companies and developers recognize the importance of safeguarding user information. Great applications do that through the following criterion:

  1. Transparency in storage and use of personal data;
  2. Consent and Control of what personal data is made available;
  3. Security and Protection of personal data, through encryption;
  4. Use Limitation, to only what is required, at the time that it is required.

This article will dive into why it is vital that developers adopt it, and subsequently, ways in which you can implment it it in your iOS app. 

WHAT IS DIFFERENTIAL PRIVACY?

Differential Privacy is in fact an obscure branch of mathematics that aims to analyze a group more, whilst annonimizing individual users. The thesis was aithored by Professor Aaron Roth of the University of Pennsylvania, and Apple has not only embraced this as a service that will flow through its own services, but strongly advocating it for its third-party developer community. 

“The concept behind differential privacy is the idea of obscuring or introducing ”noise“ into big data results to mask individual inputs while still getting useful information on larger trends ” according to Roth (as cited in AppleInsider), ensuring that individual information is not revealed, but still gaining a sample representation, for statistical purposes. 

Apple has already started roilling out differential privacy on their apps and services, starting from iOS 10. On their messaging app, Apple is better predicting user input based on words used via aggregated big data. Apple has improved its search suggestion feature, where it previously ensured all Spotlight data was stored only locally, with developers deciding what data to share in spotlight (through indexing). 

With the latest iOS iteration, users will choose whether to submit more public data about their activities, and Apple adds random noise to make it impossible for data to be traced back to single users. 

Differential privacy addresses anonymity by providing enough information about a crowd, without the association of the individual, but with enough answers the noise of randomness could deduce through calculation to produce a relatively accurate distribution. There are some problems that are inherent with differential privacy

LEVEL OF DATA COLLECTED

Data is partially recoverable, depending on on how much data from an individual party is collected. Apple resolves this through sending a subset of data (a small sample), similar to exit polls in elections, representing the intended distribution. 

Suppose you have access to a database that allows you to compute the total income of all residents in a certain area. If you knew that Mr. White was going to move to another area, simply querying this database before and after his move would allow you to deduce his income. The answer is to create an approximation of the total income, getting accurate information whilst protecting Mr White. (source: (Neustar))

LEVEL OF NOISE USED TO OBSCURE DATA

Another issue, as we had pointed out, what if there are only a few users, or a small sample, due to the size of the distribution? How much noise should be used to obscure data? Apple when adding noise, also disregard some data on a regular basis, whilst other get uploaded, meaning data is transient, rather than historically emperical, adding more weight to the noise aspect. 

“Users can opt to not send any data at all, he says, and Apple will additionally discard IP addresses before storing information on its end to avoid connecting even noisy data with its origin” (source: Macworld)

The level of noise is adjusted depending on the density of the sample, such as if there are only two or three users, you will want to adjust your noise more, to ensure that the data count never deduce back to any individual user. If say there are only one or two people in a village, Apple will introduce noise, ensuring you know the frequency but not the whom

LEVEL AND FREQUENCY OF THE SAME QUESTION ASKED

Asking users the same question, or even similar questions across a specific time-period can also lead to the de-anonymity of data. 

…asking too many similar questions, matters become more subtle. If you ask someone if they’re a member of the Communist party, and then ask if they admire Joseph Stalin, and then ask the ideal economic and political system, and so on, it’s possible an outside observer would eventually penetrate through the noise and determine an attitude on a given topic…. (source: Macworld). 

This leads us to the subject of privacy budget.

Privacy Budget

Privacy budget is the notion of limiting how much data from the same (or related subject) is transmitted over a period of time. Premised with the fact that asking the same question over and over again over a short period of time, and getting the same answers could lead to determining the truthful answerprivacy budgets are scales that developers work with to balance the reliability of collected and aggregated data against the prospects of re-identification

This is a complicated mathematical theory in itself, which is best illustrated in Anthony Tockar’s research paper. Suffice to say, the privacy budget measurement is a more important control measure than the statistical upper bound of a query, so that once a query budget is exceeded by the user, the user will not be able to make any further queries. This is what essentially defines diffrential privacy and privacy budget.

Other Measures to Secure User Data

I mentioned at the start of this article, the four important aspects that amount to the secure guardianship of your user’s data, together with differential privacy

TRANSPARENCY

Users demand transparency when it comes to how their information is stored and used, so providing disclaimer to that effect is imperative, as a good model citizen developer. They still own their information, giving you access to their information means they need to understand how you plan on using their data.

In iOS 10, Apple’s Advertising network has an icon that allows users to see how some of their non-identifiable data made the ad relevant. 

 

CONSENT & CONTROL

0*7e0CKegCmLHKbpWM.png

This leads onto consent and control, giving users the ability to consent as to whether they want to give you information, and how much information to give you, as well as the ability to rescind their permissions. This should be explicit, and iOS for the most part provides an easy way for you to ask permission before you access their personal information, be it address bookphotos librarylocation and so on. 

Whilst system settings affords users the right to revoke permissions, you should make it easier, by including in your app, menu settings that allow for toggling as well as adjusting different permissions, in an easy way. Most importantly, if the user does rescind permissions, they don’t get a poorer experience, but instead get a less identifiable experience. 

 

SECURITY & PROTECTION

Of course, it goes without saying that the information you take consentually should always be securely stored, through enryption, using best-practices. If you are unable to provide strong encryption, don’t store personal information, its a simple as that. If there is a breach, as has been the case with numerous companies, like LinkedIn, reset user’s passwords immediately and provide them with notice, expeditiously. 

USE LIMITATION

Finally, use limitation refers to only taking what you need, not what you want, in a timely manner. Understand what statistics you need, and take only the attributes that make that, rather than setting a blanket Facebook permissions box that asks for everything, in the hope that some of it may be useful to you. 

Conclusion

Differential Privacy is a highly theoretical mathematical concept, that was devised some few years ago, but with privacy front-and-center in people’s minds, Apple have decided to make this part of their platform for iOS 10 and beyond, despite there not being widespread proof that this works in practice. Safeguarding user privacy, Apple have nevertheless placed a lot of trust and effort to push this initiative. 

Through privacy budget, this methodology promises to gather crowd information without distinguishing individual users, through the addition of noise, as well as through the sampling of smaller subsets of distributions. 

This is a very interesting area, and with Google also expressing an interest in the theory, we may see this as the future industry-standard. In fact, this may eventuate to the arms of governments where future legislation may entrust companies with stricter compliances. On a final note, I would recommend watching Apple’s Engineering Privacy for your Users WWDC session, which provides an excellent insight into Apple’s take on the theory. 

Citations and References

What is ‘The Minimum Marketable Product’?

The minimum viable product (MVP) is a powerful concept that allows you to test your ideas. It is not to be confused with the minimal marketable product (MMP), the product with the smallest feature set that still addresses the user needs and creates the right user experience. The MVP helps you acquire the relevant knowledge and address key risks; the MMP reduces time-to-market and enables you to launch your product faster. This post discusses both concepts, and it shows how you can use the minimum viable product to create a minimal marketable one. 

You have heard of the minimum viable product(MVP) no doubt, well product managers have what is called the minimum marketable product (MMP). MMP is a product or service that meets the selected customer’s needs.

The minimum viable product (MVP) is a powerful concept that allows you to test your ideas. It is not to be confused with the minimal marketable product (MMP), the product with the smallest feature set that still addresses the user needs and creates the right user experience. The MVP helps you acquire the relevant knowledge and address key risks; the MMP reduces time-to-market and enables you to launch your product faster. This post discusses both concepts, and it shows how you can use the minimum viable product to create a minimal marketable one. (Source: Roman Pitchler)

Take the Apple Watch for example, it’s marketable customer needs are indeed narrow, and rather than being a device for the masses, it satisfies a particular niche market. As opposed to regular watches, Apple’s smart watch provides the ability to receive notifications from your iPhone, an extension that notifies the user through a vibration, when a text message, or phone call is coming in, or an in-app push notification is happening.

Whilst limited, the users can also use their smart-watch to send pre-baked text messages back, as well, and whilst it has an app ecosystem, the apps are meant to be a mere extension rather than replacement to one’s phone.

The obvious benefits of an MPP is that it speeds up development-time-to-market, with lower development effort and larger return on investment. An even greater benefit, is the quick time-to-market means product owners can listen to their users quickly. Even if in the case of Apple they are mostly early-adopters, that vital early and rapid feedback especially in a new category of products means the company is able to respond, adjust and pivot more rapidly.

The least rigid the future roadmap of the product, the better it is, because your roadmap should pivot and adjust dynamically, based on user feedback and reactions, and a minimal product as far as functionality means precise and targeted feedback is more readily available, more focused with the allowance for each individual features and components to be individually validated.

MMP is more focused on less is more, smallest feature-set. That addresses the users needs, with the right level of simplistic UI t hat can be sold and marketed successfully.

The key to creating a successful MMP is to “develop the product for the few, not the many,” as Steve Blank puts it, and to focus on those features that make a real difference to the users. To discover the right features, the MVP is a fantastic tool. (Cited in Roman Pitchler)

3 Ways a PM can help the team De-stress

With Project deadlines looming, stress is often a factor that project managers have to deal with, especially with the team they are managing, with a clear correlation between the level of stress indured and the quality of work produced, not to mention emotional endurance. Let’s face it, almost every project (most likely every project) is under the pump at one stage or another during the lifecycle, and duress is something, as a Project Manager, you certainly need to deal with. 

With fixed resources, fixed time and budget, things tend to go awry, whether it is a strong dependency of a delivery from one team, a technical difficulty that cannot be resolved, scope changes, resource changes, and your job is to make sure things don’t go belly-up. Negative stress influences teams by de-optimizing their work efficiencies, resulting in lower-than-expected sprint velocities, dampen creativity and constructive thinking, resulting in mental fatigue, resulting in even simple coding errors creeping in.

There are of course specific PM courses of action you can take to address the problems, and this article isn’t about that, it’s more about how you can leverage your influence to act as a mentor, or guru to project positivity, in order to boost the morale of your team. Here are 3 Ways a PM can help the team De-stress.

With Project deadlines looming, stress is often a factor that project managers have to deal with, especially with the team they are managing, with a clear correlation between the level of stress indured and the quality of work produced, not to mention emotional endurance. Let’s face it, almost every project (most likely every project) is under the pump at one stage or another during the lifecycle, and duress is something, as a Project Manager, you certainly need to deal with. 

With fixed resources, fixed time and budget, things tend to go awry, whether it is a strong dependency of a delivery from one team, a technical difficulty that cannot be resolved, scope changes, resource changes, and your job is to make sure things don’t go belly-up. Negative stress influences teams by de-optimizing their work efficiencies, resulting in lower-than-expected sprint velocities, dampen creativity and constructive thinking, resulting in mental fatigue, resulting in even simple coding errors creeping in.

There are of course specific PM courses of action you can take to address the problems, and this article isn’t about that, it’s more about how you can leverage your influence to act as a mentor, or guru to project positivity, in order to boost the morale of your team. Here are 3 Ways a PM can help the team De-stress.

#1.Empathy

The most important attribute I believe a project manager should possess is empathy. Empathy – em·pa·thy – the feeling that you understand and share another person’s experiences and emotions : the ability to share someone else’s feelings (source: Merriam-Webster Dictionary)

Measured as emotional intelligence, a powerful leadership quality is the ability to connect with each of your team-members on a non-technical, but emotional level, and understanding their needs, concerns and helping build a stronger and safer mental state for your team-member.

“Leaders with empathy,” according to Dr Daniel Goleman of the Harvard Business Review (“What Makes a Great Leader”), “do more than sympathize with people around them: they use their knowledge to improve their companies in subtle, but important ways.”

This tool, empathy is powerful not just in the sense that it allows you to help console a team-member, but also a strong negotiating tool. That is, empathy doesn’t infer you need to agree with someone, but rather substitute agreement for empathy, showing a genuine concern for the other person’s concerns, feeling and motives, thereby portraying a greater level of reasoning that leads to a response that is in tune with what the person is going through.

#2. Rallying Your Team

Empathy should not just in the form of words, but actions, and you know the saying work hard, play hard, that’s something that PMs should always do. Ideally, you want your team to bond and gell well, in order to build a strong sense of synergy and dynamics, and while that takes some time to form, you need to help facilitate the fostering of positive relationships. One way of achieving this, is through providing down-time, or socializing activities for your team. 

For instance, start with something simple as pizza Fridays, catered lunches during meetings, and lunches outside of the office. Allow your team members to get to know each other on a more personal level, and the bond will directly translate into the team rallying together for a common cause, or goal. 

One analogy I like to give is to compare it to the ancient Roman or Greek battle-cries, where a strong army morale with inspiring rallying, leads to armies defeating other armies of even greater sizes. Morale therefore is one of the most powerful emotional states a team can have. 

“Schedule monthly get-togethers to reaffirm the project goals, congratulate the team on their successes to date and boost their confidence in doing what it takes to complete the project successfully. Make sure that each person leaves the meeting energized and passionate about finishing the remainder of the project.” (source: Jason Westland. “Managing Projects of all Sizes.” ProjectManager.com, 2014)

With sprints, this is also where retrospectives come in, where you always make sure that you recognize success, and attribute success to each member always. 

#3 Prevent Negative Members from Influencing the Team

Sometimes its not external influences but internal influences that causes stress in the team. It could be someone from another team, say a product owner, that is the instigator. As a Project Manager, you play a fundamental role in shielding your team from negative outside influences, you bat for the team, advocate for the team (I’m looking at you, overzealous product owners).

Identify the instigator and use your personal negotiation skills (remember we talkd about empathy as a tool as well) and directly come to agreements so that they go through you. While listening to his or her perspective on the matter, you also put forward a strong stance that you won’t tolerate negative influences on the team, to hinder their performances. 

If the instigator is someone from within your team, you need to quickly pin-point the stress point (weak points) early on, provide a concrete action plan that will improve the situation. Of course, to be respectful of that person and everyone else, do this in a private manner. 

Remember, as a PM you need to always practice what you preach, and be a positive influencer, for others to follow. You don’t lead through authority but rather through influence, so your charismatic and empathetic attributes as a great leader will greatly determine whether your team is performing at its optimal or not. Rubbing out negiative influences, and instead rallying around your team, with positive re-inforcement, will allow you to achieve more, with less, all thanks to the comradership of each of your team-members.

Co-Founder Conflict is the #1 Startup Killer. How Can You Protect Your Startup

Conflict Resolution Management is a skill that many trained project managers learn, when working with stakeholders, but something that young entrepreneurs never learn, until it really happens. In fact 62% of startups fail because of co-founder conflicts, and it’s something that really scares venture capitalists. In fact, there’s a saying in Silicon Valley that it’s better to have an A team with a B idea, than a B team with an A idea

The composition of co-founders vary, from two best friends who decide to work on an idea together, to ex-college classmates who decide to form a company, to colleagues at work who decide to co-found a company. Picking a co-founder is critical to the success of a project, and in most cases, you pick someone you really know and can work with, with a proven track record of collaborating together, but still, conflicts inevitably happen sooner or later, so what can you do about? Firstly, let’s identify the types of conflicts that co-founders commonly get suckered into, and the common conflict resolutions to solve those. 

Delegation of decisions

Say one co-founder may like an idea, but the other doesn’t, we suddenly have conflict. This usually occors when you don’t divvy up the duties and responsibilities clearly enough, to have boundaries that you can each respect. Usually a good composition of co-founders is one where each of their skills are complementary, say one is more tech-savvy whereas the other is more business-savvy. 

By setting clear deliniation of responsibilities, you should trust in the other’s capabilities to make decisions. You should of course provide a diplomatic mentality to set out your reasons why you may disagree, but ultimately, once you’ve done your best to convince, show your faith and trust in the other co-founder by letting him have ownership over his decisions. The worst that can happen is, you try the decision and if it doesn’t work out, pivot, because one thing startups have over larger companies, is that they can pivot more rapidly because they are far more in-tune with their markets. 

A Co-founder works harder than the other

So, we aren’t really going to envisige a modern startup with punch-cards right? I don’t think in any scenario you will find each co-founder working the exact amount of hours, all the time, consistently. So get that expectation out of your heads right away!

Comparing a technical co-founder and her programming efforts, up against a marketing co-founder that is working on cultivating a user-base, is like comparing apples and oranges. There may be quiet times for business co-founders, or designers, whereas the coding effort is still going at full-steam, but the next week things may change, and they may end up doing crazy hours trying to reel in new deals. 

This goes back to the first point above, where co-founders need to trust each other, and delegate responsibilities appropriately, and if it seems like there is a continual uneaveness in workload, discuss that and see if you can offload anything to even out the work. 

Equality in Equity

Related to the previous point, discussing who gets how many shares in the company. This is a very contentious issue and something that really riles up co-founders. Does the co-founder that came up with the idea get more than the rest? Does the CTO get more than the CFO? 

Well, I can tell you, if you all started out at the same time, divide it up equally, it’s that simple! It won’t matter in the end if you distrust each other, or let greed give one person more equity, because you won’t even have a product, and venture capitalists won’t even want to touch your toxic environment.

When Diplomacy Fails

When all things fail, seek outside counsel. I always recommend companies have at least 5 mentors, as well as board directors outside of the company, because it adds an outsider’s perspective, balance and wisdom that you definitely don’t have. 

Getting an outsider to broker your disagreement will allow you to move on, so think of it as couples therapy for co-founders. You hate to be in this situation, but you have to agree to the outcomes, and going through the tough times with respect and civility will make you greater negotiators. 

In Conclusion

Nothing venture capitalists hate more is co-founders who cannot get along, and if they sense anything like that, they will pull-out as soon as they can. Maturity and conflict resolution are not attributes that young co-founders have instilled in themselves, but something that needs to be learned quickly. Being civil, open-minded and remembering that you don’t convince with authority but rather by selling your points makes for a healther debate, than being abrasive. 

Everyone co-founders options should matter, but you should also have a structure in place where responsibilities are delegated clearly, and co-founders lean on each other for consel. Ideas will change, and companies pivot many times, but if you turn your relationship with your other co-founders into a toxic one, it will eventually break your company, and will be part of your resume when you work on another startup. 

Sunsetting a Product Feature

Product Managers are inevitably fallible, and features you once thought would be something your customers would embrance, end up being ‘dead-wood’. That feature is not given nearly attention you have envisiged, and you decide to put it out to greener pastures. It happens, every company does it, big and small, like we just saw this week, when Facebook shut down it’s Parse services, but how does one go about sunsetting a product feature?

While the feature isn’t extremely popular, you still have certain number of customers using that feature, and you need to ensure minimal customer impact whilst also preventing your app from becoming bloated. Of course, to make sure your feature is indeed a candidate for deprecation, conduct the following:

Determining the feature is indeed ‘dead-wood’

FIRSTLY, WORK OUT HOW MANY PEOPLE ARE ACTUALLY USING THAT FEATURE

Through your analytics tool, and feature metric-tracking, you should be able to assert how many users (as a percentage) use that feature, compared to the rest. If its a specific plan tier (i.e free tier), a specific function (i.e follow a user), note down the %. 

The percentage of course needs to be based over-time, rather than indefinitely, so set a baseline for what you determine to be frequently (i.e once a day, once a week, once a fortnight). The importance is you are looking for retentative usage metrics, not acquisition usage metrics

SECONDLY, WORK OUT REVENUE OF THE FEATURE

In addition to percentage of users, assert how lucrative that feature is as a percentage as well, over a specific period of time, such as a quarter or year. This will then allow you to determine firstly how insignificant the revenue is, and secondly, that the revenue is indeed falling over time.

FINALLY, UNDERSTAND WHY THE FEATURE ISN’T POPULAR

You need to ask yourself, and more importantly, ask your customers why they weren’t using it. Send a Mailchimp survey, or within the app, ask your users a quick one or two question survey, which will help assess whether it’s due to function or awareness. This will also help answer whether you have done all you can to make the feature aware, or the feature in fact addresses a tangible customer need. 

If after those steps you determine that the feature should be deprecated, it should be done delicately, with minimal disruption, and maximum forewarning. You start off by not allowing new users (those who have just signed up or haven’t used the feature) access to the feature. 

For existing users, you then send out an email explaining that you are removing the feature, and why you are removing it, giving them ample time to backup or transition. Facebook with it’s Parse deprecation is giving its users up to one year to transition out. Ideally, you should provide them with a utility and guidance on how they can migrate out data from that feature, if applicable (i.e a calendar). You can also give those users some suggestions on alternative tools available that can solve that need, which in the case of Parse, Facebook recommended Amazon AWS or Microsoft Azure. 

So to summarise, ensure you provide a clear and concise message letting the users know: * that you are sunsetting the feature; * when you are going to sunset the feature (precise date), * why you are doing it; * alternative solutions; * migration guidance and tools for users to get out the data; 

Determining to sunset a product feature properly, with due diligence, and then managing existing user expectations properly, with clear and concise communication is key to deprecating a feature. If you fail to do it properly, you raise the prospect of users becoming disgruntled, unsettled and concerned that other features they rely on may fall unexpectedly as well. 

Loose the feature without loosing your customers, that is the key lesson!