Prompted by this reddit thread, the question in the title seems to be a fairly common one among Computer Science undergards as well as those that are just now starting up in the field – What programming language should I choose? Is there a possibility that I will choose the wrong one? Should I learn one or many?
Before going any further into this post, I should preface this by saying that anything and everything below is purely my subjective view on what makes a Program Manager a great Program Manager. I consider myself lucky enough to have experienced what it’s like to be a PM on a product team, and currently – on a content team, and this blog post is a reflection of my experiences across the two completely different organizations.
A while ago Microsoft released this wonderful thing called the VSO agent – a cross-platform build agent that you can set up on MacOS X and/or Linux and hook it directly to a VSO or TFS instance to handle automated builds with a lot of customization options. You can get it here.
So here comes the challenge – more often than not, the build agent should be automatically set up, but the documentation mentions that the instance details, such as the service URL, username and password are manually entered. Not exactly what you want to do in an automated scenario. The good news is that there is a (not so) secret option to use command line parameters for the vso-agent:
With the release of Outlook Groups, I got a lot of questions regarding the possibility of conversion of existing distribution groups to the new model. Instead of having users manually go through the process, I wrote a sample that demonstrates how it’s done with the help of EWS and Active Directory APIs. So how do you set it up?
Clone the repository here: https://github.com/Microsoft/hummingbird. You will get the project file with the associate source files. Open the project file (Hummingbird.csproj) and save the Visual Studio solution. Next, click on Manage NuGet Packages…
In the package manager, notice that there is an alert notifying you about the fact that you need to restore missing packages. Click on Restore.
Once you have the packages restored, you can build the project and run the application:
From here on, you will be able to use the application directly with O365. Click on Settings to configure all application parameters:
For the username, use the standard O365 email address. The server URL for the main EWS endpoint is https://outlook.office365.com/EWS/Exchange.asmx – make sure that you also select O365 as the target. Once you enter both the credentials and the server information, click on the respective Save buttons.
Moving forward, you will have everything required for migration. On the main page, you can enter the alias of the DL (skip the domain) and click on Create Backup. The output (as long as the alias is resolved) will be an .xmldl file that contains the original alias, DL owner and list of members. Hummingbird will not automatically delete the distribution list for you, so nothing to worry about. You can use this .xmldl file in the next step when you will create the group. If you want to preserve the alias, you will need to manually delete the DL first. Otherwise, the new group will be created with the new alias and a list of members from the original DL. Every member of the new group will receive a welcome email upon completion.
In a world where everyone is trying to collect and analyze data about their product, it is easy to get excited about numbers. After all, getting hard numbers about what you shipped is, in a way, validating or invalidating the provided value. The problem comes down to those numbers being presented in an exciting, or worse – misleading, way (refer to a16z’s 16 more startup metrics).
The two terms that I often hear being thrown around are usage and engagement. Now, there is, of course, nothing wrong with leveraging both to make decisions, but it is important to keep one thing in mind – they are not the same. So whenever these two terms are used interchangeably, intentionally or not, a mistake is made that loses the key differentiator between them and can potentially create a false sense of security when the product is failing to hit its actual performance indicators.
Usage is a value that describes a number of certain actions taken against a feature, or the product as a whole, that do not represent the actual usefulness of either. For example, number of clicks on a specific button as a standalone metric is pure usage. How many times a user clicks on a profile picture? Usage. Number of downloads? Also usage. None of this maps 1:1 to engagement. Because you have sixteen thousand clicks on a button means nothing for how much value it provided to the user – for all we know, the user might’ve been frustrated enough where he or she clicked a couple of times and quit the app. Great, so now you have clicks, but an unhappy user. See where the issue is?
On the other hand, engagement measures user interaction with the product in a much more holistic way, where it ties in a lot of what we discussed earlier. As an example, think of it as a way to correlate time spent in the product, feature usage, number of returns to the product in a day and conversion rate (read: user achieving a goal established in the product). Now, looking at the high-level picture, you can see just how much your product is achieving in terms of business goals.
So we end up with this:
Usage is a component of engagement. Not a synonym of it.