Deleting Multiple Items on Azure

Probably for good reason, there is no easy way to delete a bunch of items from the Azure portal. This means drilling into each of the different items, clicking on delete, possibly confirming something by typing its name into a confirmation screen, waiting a minute for the operation to complete, and then advancing to the next. Totally acceptable for production assets, where you may seriously regret deleting the wrong database (and there is no undo!).

But, when you are developing on Azure, you end up creating a ton of assets, and deleting them one by one is slow (and you actually may go on auto-pilot and end up deleting something that DOES matter). Even worse, some assets do not have a delete option in the portal (hello ADF V2…still preview, so I get it).

The trick to deleting a bunch of items is to use a resource group. Start by navigating to one of the items that you want to delete, click “change” next to resource group, and then you have the option to move a number of items into a new resource group called…trash or something like that. Once all of the items have finished moving to the new resource group, you can delete everything in once fell swoop by deleting the resource group. Pretty clever, huh:).

Have any tips and tricks to share on the Azure portal? I would love to hear them.



Add New Related Table for Entity Framework

If you are building an ASPNET MVC application (or Rails, or CakePHP) that leverages migrations, the productive speed is pretty amazing…until you do something that is not on the critical path. One area that I THINK falls in this category is adding a NEW table that an EXISTING table will use as a foreign key (e.g., the EXISTING table needs to add a reference to the NEW table).

Here is how I did it.

  • Create the NEW model / class / table
  • Update the model for the EXISTING table having a reference to the NEW table
  • NOTE: do NOT add a reference from the EXISTING table to the NEW table, because this will break referential integrity tests
  • Create a migration for that NEW table and updated EXISTING table
    • Update the migration to specify that the default value for foriegn key (e.g., typically it is 0 for ASPNET MVC, and my first record will be a value of 1, so I specified a default value of 1)
  • Run the migration so that your NEW table will appear in your database
  • Create the CRUD scaffolding for the NEW table (so that you can create a proper entity
    • you can just insert a record into the database, but if you have relationships to user accounts or other logic that may be tricky
  • Using the web interface, create your first entry for your NEW table
    • You will need to do this for each environment…dev/test/production…where you want it to apply; if you just push the final solution to production, you will get an error until you manually create the first record and populate the reference to the first record
    • NOTE: my favorite approach for updating different environments is to point my local dev instance at the production database, run the migrations, and even run the web app – not good for significant implementations, but super fast for smaller projects
    • If needed, manually update your database for the EXISTING table so that all of them point to that newly created record
  • Now add the reference from the NEW table to the EXISTING table, create another migration, and update the database again

It seems a bit hacky, particularly because you cannot just deploy. But, given that it took me longer to write it up than to do it, I went with the approach.

If you have a better approach, I would love to hear it.



What is a Product Manager?

There are a lot of great posts about what a product manager is (like here and here), but there is only one problem: none of them say the same thing, because there is no globally accepted definition of the role. In some organizations, a product manager keeps the trains running on time, in others the product manager is “CEO of the product”, and in others the product manager is the voice of the customer.

One thing that most product managers (and organizations that employ product managers) agree on is that data beats opinion, so I decided to put together a highly scientific test to figure out what a product manager really is, as defined by the “customer” that is buying product managers. In other words, I grabbed a couple dozen product manager job postings from LinkedIn, selected  9 high-quality postings (well written, specific requirements, clear scope), and then identified common features present in posting. This experiment was far from perfect, but I did see some patterns that I found interesting.

So without further ado, here is a visualization of the data:

Product Manager Features

The most interesting point to me: no job feature was required by more than 2/3 of these product management jobs. Other interesting points:

  • Most companies want experience managing the product roadmap, from “Define, develop and communicate the product roadmap” to “You have experience in creating product roadmaps that are focused on achieving business goals” to “Own the roadmap, influence product and technology strategy and direction (roadmap).” Fun fact: I bet no 2 companies agree on what a good product roadmap is:)
  • Product management experience is typically expected, and 5 years experience seems to be a sweet spot.
  • Continuous customer discovery / voice of the customer was common, but not universally explicitly required, which I find crazy. If I was to pick one attribute that a solid product manager needs, it is an obsession with the customer. Product management experience you can acquire (everybody starts somewhere), and skills like building product roadmaps can be learned, but a lack of focus on the customer seems like it should be a non-starter.

One job feature that I found interesting in its absence was DevOps. I have a hunch that as customer / product feedback loops get tighter, the product manager is going to need to get closer to the DevOps process. Knowing how to get an experiment/feature into the wild and ready to gather data on whether it is working, and gathering this data as quickly as possible (and either double down or revise) seems like a natural experience to demand of your product manager. I am not saying that product managers will drive DevOps, but they should be familiar with it…where a feature is in the release process, when it is live (and for whom), etc.  But, alas, I am on the outside here, and not one job description mentioned anything about DevOps. Five of the postings did mention Agile, which in combination with DevOps, form the foundation of the feedback loops, so perhaps it is just assumed some familiarity with how features get operationalized and released to the wild is part of the product manager’s bag of tricks.

Let me know if anything jumps out at you, or if you have opinions that diverge from this highly scientific study. 🙂




Ps-here is the text associated with the graphic above:

Roadmap Development 6
Continuous Customer Discovery 6
Product Management Experience 6
Excellent Written & Oral Communications 6
Analytics/Data Driven 6
Bachelors Degree ++ 5
Agile Expertise 5
Strategy/Market Requirements 5
Project Management 4
Dev/Sales/Marketing Bridge 4
Business Planning 4
Technical Expertise 3
Proven PM Capabilities 3
Detailed product/business requirements 3
User Acceptance Testing 3
Backlog Management 3
Deliver V1 (version one) 3
Trendspotter 2
Public Speaking 2
User Experience 2
Roadmap Execution 2
Go to Market 2
Creative 2
Influence, Relationships and Teamwork 2
Stakeholder Management 1
Product Marketing 1
AB Testing 1
Team Management 1
New Product Pitches 1


Product Roadmaps (and Product Managers) Discussion

Just listened to a good podcast from Janna Bastow on building product roadmaps. In 24 minutes, here is what you will here:

  • Start with what problem are you solving and for whom.
  • 2 sources of input for roadmap
    1. Top down product management: vision + objectives + big steps
    2. Bottom up approach: conversations with customers, team, competitors – in the trenches.
  • Challenge – dealing with tons of data from customer, prioritizing, and communicating
  • How to address getting input from the team into the product plan: product tree game
    • Innovation Games was the inspiration
    • Put people from multiple disciplines in a room and put a huge tree on the white board
      • Trunk represents the core – foundation
      • Infrastructure is represented by the roots.
      • Ideas are the branches.
      • Have a bunch of post it notes and put them on the tree
  • Separate release plan (2-4 weeks out) from roadmap to give you agility – roadmaps do not have dates.
  • 3-6 months out for roadmap is reasonable for an immature product; 2 weeks is sprint for them. 
  • Roadmap should not be a set of features; distill out the higher level meaning of the features into more meaningful themes.
  • Every product should have objectives and metrics – but how do you measure the effectiveness of a product manager? Who knows:)
  • Is the HIPPO hijacking the roadmap? Stakeholder management and saying no are critical skills for a product manager.
  • Who else is doing interesting work in the product management thought space? Nate Walkingshaw, CXO at Pluralsight

Getting NYC Taxi Data into Azure Data Lake

I wanted to get a meaningful dataset into Azure Data Lake so that I could test it out. I came across this article, that walks through using the NYC Taxi Dataset with Azure Data Lake:

The article kind of skips over the whole part of getting the dataset into Azure. Here is how I did it:

  • Spin up a VM on Azure
  • On Server Manager, click on Local Server, next to IE Enhanced Security Configuration click the On link, and at least set Admin to Off (or else you will have to click ok a dozen times a web page)
  • Download the files from the NYC Taxi Trip website to your VM
  • Install 7-Zip so that you can unzip the 7z files.
    • Once you install it from, go to the install folder (probably C:Program Files7-Zip) and right click the 7z.exe file. Select the 7zip > open archive option and then click the + sign and browse to your downloads folder
  • Because the files in the trip_data.7z file are larger than 2GB, you cannot upload them using the portal, and you need to use Powershell.
  • You need to install the Azure PowerShell Commandlets – look for the Windows Install link a bit down this page
  • You will probably need to restart the VM for the Azure commands to be available in PowerShell
  • Go wild on Azure Data Lake Store using this doc – here are the key steps:

 # Log in to your Azure account

# List all the subscriptions associated to your account

# Select a subscription
Set-AzureRmContext -SubscriptionId “xxx-xxx-xxx”

# Register for Azure Data Lake Store
Register-AzureRmResourceProvider -ProviderNamespace “Microsoft.DataLakeStore”

#Verify your ADL account name

#Figure out what folder to put the files
Get-AzureRmDataLakeStoreChildItem -AccountName mlspike -Path “/”

NOTE: if you do not want to copy the files one-by-one, you can just copy the whole folder using this format: Import-AzureRmDataLakeStoreItem -AccountName mlspike -Path “C:UsersTaxiDesktopfiles2trip_data” -Destination $myrootdirTaxiDataFiles

Once you have the files uploaded to Azure Data Lake, you can delete the VM.

If you know of a faster way of getting them there (without downloading them to your local machine), I would love to hear it!



Startup Dilution Explained as Simply as Possible

I had the opportunity to run Microsoft Azure’s Startup Accelerator in 2013. For 2 programs, we helped about 10 startups accelerate their businesses during a 3-month startup boot camp. Since Azure was the sponsor, there was a bit of technology work done, but the biggest gains for the startups were: 1) in their understanding of their customer and their business model; and 2) in their understanding of the mechanics of startup funding. To this day, I still find dilution over several investment rounds to be one of the most super-complex and super-intriguing concept in the startup funding space.

Why Do We Need Dilution for Startup Fundraising?

Before jumping into the mechanics, let me ask you a question: why do we need to dilute investors at all? If you were only going to raise a single round of funding, you do not need to dilute investors at all. You would say “I will give you this much of my company in exchange for that much capital.” Eventually, you either will come to terms of selling X% of your asset for $Y, or you will not, but dilution does not enter the equation.

Dilution only becomes an issue when you are going to raise capital over multiple rounds.

Why Are Multiple Round Investments Required for Startups?

For simplicity’s sake, let’s assume you have a really clear capital requirements ($100,000 needed today, $200,000 needed in 12 months, and $300,000 needed 24 months), and the only unknown is valuation. Certainly it would be logically possible to raise all of the money ($600,000) today, but no investor would want to give you capital for a super-risky startup so that you could park most of the cash in a bank for a couple of years. So that is not a realistic option.

You could also agree on valuations today, and then collect the money in 12 and 24 months as it is needed. But what if the startup flounders for 12 months: are the investors still required to invest at the initially agreed upon valuation? If you give the investors an option to renegotiate because the startup is not “killing it,” then wouldn’t any rational investor argue for a lower valuation in 12 months so that could increase their equity for the same investment? Certainly, you could imagine a bunch of performance criteria and contractual provisions that would establish the future valuation, but given the unpredictable nature of a startup this would be an impossible task to do well.

Multiple Rounds & Dilution to the Rescue

“Let’s All Negotiate Timing, Capital to Raise, and Valuation at Each Round”

Because it is so difficult to foresee what is going to happen in terms of capital requirements and valuation with startups, raising multiple rounds of capital, and diluting founders and earlier stage investors with each round of funding, has become the norm.

Turning back to the scenario ($100,000 needed today, $200,000 needed in 12 months, and $300,000 needed  in 24 months), we establish a first round where we are just trying to raise $100,000. Back of the napkin, startup investors are going to want to acquire between 20% and 40% of the company for EVERY SINGLE ROUND OF INVESTMENT. The way to think of this is not that your company is worth $500,000 because you are raising $100,000, but that your company better be worth $500,000 if you hope to raise $100,000.

First Round: Founders Diluted by 1st Round Investors

Let’s keep the math simple and say: the startup has pre-money valuation of $400,000; we are raising $100,000; and this gives us a post-money valuation (pre-money valuation + amount raised this investment round) of $500,000. Investors will end up with 20% equity (amount raised from investors this round / post-money valuation, or $100,000/$500,000 = 20%). The founders ownership in the company is diluted by 20%, so that their initial ownership (100%) is diluted to 80% (100% * 80% = 80%…the math will get more interesting next round:).

Pre-Money Valuation  $400,000
Amount Raised  $100,000
Post-Money Valuation  $500,000
Founder Ownership 80%
Round 1 Investor Ownership 20%

Second Round: Founders and 1st Round Investors Diluted by 2nd Round Investors

Fast forward 12 months, and the business needs to raise $200,000. The 2nd round investors may be the same set of investors or a new set of investors. The math is easiest if you assume they are different (and if there is an overlapping investor, she will be entitled to the sum of their first and second round of equity).

Assuming that the second round of investors want to acquire 20% of the company, we will see dilution in action. The 2nd round investors will get 20% of the equity, leaving the founders and the 1st round investors with 80% of their original equity positions.

 Round 1  Round 2
Pre-Money Valuation  $400,000  $800,000
Amount Raised  $100,000  $200,000
Post-Money Valuation  $500,000  $1,000,000
Founder Equity 80% 64%
Round 1 Investor Equity 20% 16%
Round 2 Investor Equity 20%

This may seem like a bad outcome for the 1st round investors, because they have been diluted from 20% to 16%, but they are better off. Now they own 16% of a $1,000,000 asset (or $160,000) instead of 20% of a $500,000 asset (or $100,000). The key for the early stage investors is that the asset needs to be growing faster than they are being diluted (when the dilution exceeds the increase in valuation, so that the early investors are financially worse off, this is called a down-round, or a bummer).

Third Round: Founders, 1st & 2nd Round Investors Diluted by 3rd Round Investors

Another 12 months, and we need to raise another $300,000. You know the drill, so here is the table.

 Round 1  Round 2  Round 3
Pre-Money Valuation  $400,000  $800,000 $1,200,000
Amount Raised  $100,000  $200,000 $300,000
Post-Money Valuation  $500,000  $1,000,000 $1,200,000
Founder Equity 80% 64% 51%
Round 1 Investor Equity 20% 16% 13%
Round 2 Investor Equity 20% 16%
Round 3 Investor Equity 20%

Startup is Sold (Hooray!)

Let’s assume that a year after the last round, we sell the company for a cool $3 million dollars. The funds are distributed in accordance with their final round equity positions.

Round 3 Sale
Sale Price  $3,000,000
Founder Equity 51% Founder Payout  $1,536,000
Round 1 Investor Equity 13% 1st Round Payout  $384,000
Round 2 Investor Equity 16% 2nd Round Payout  $480,000
Round 3 Investor Equity 20% 3rd Payout  $600,000

Even though the Round 1 investors are heavily diluted, they end up with a 284% ROI (after invested $100,000), while the Round 3 investors had no dilution, but a “measly” 100% ROI.  There are differences in the time value of money (1st round investors have their money tied up for 3 years), but that does not cause the difference in return. The main reason that the early investors get outsized gains is because they took significant risk. As the startup becomes more mature, the odds of failure become less (even though they are still high) and the returns typically reflect this decrease in risk.

Dilution Mechanics: That Was Not So Bad

The mechanics of dilution are not too bad when you break them down as a simple math problem. Where it gets complicated is when you throw in reality: what are your actual capital requirements (amount and timing of cash required to grow your business), what valuation will maximize your startup’s overall probability of success (not just closing this round), which investors are going to be most helpful to your company (if you are lucky enough to be able to choose), and how much time should you invest hunting investors instead of generating non-dilutive capital (aka – customer revenue:).

I hope that you found this useful. If you have any questions, drop me a comment. Thanks, and good luck favorably diluting your early investors!