Steve reads his Blog

Data, Data everywhere, but not a drop to drink.

Originally posted on March 7, 2012 Some of you younger whippersnappers may not remember the days when data was stored in file cabinets. That's not a metaphor, I mean actual metal file cabinets. It's true! In the olden days, we used to have rooms full of them. We had a cabinet for employee records, another one for customer records, and others for tax records, financial records, payroll records, marketing records, sales records, active projects records, closed project records, old Elvis Presley records... let's just say lots of cabinets. If I wanted to get an accurate picture of a particular client relationship, my secretary, Doris, would go to about five different file cabinets and copy pieces of paper and staple them all together and hand it to me. Then one day, software showed up and we started keeping records in folders on hard drives. Of course we did not trust software so we still kept records the old way also. ironically, technology actually added to our workload. My, how far we have come. Now we have multiple applications for every aspect of our business, and most of our data today is stored electronically in various databases. There is only one file cabinet left for those items that for some reason we still feel we need a hard copy. We have applications for everything: project management, ERP, Payroll, CRM, Business productivity, website CMS, email, document management, etc, all neatly storing their respective data in various databases and electronic folders. But something else has changed to; now if I want to get an accurate picture of a particular client relationship, I have to do it myself, because Doris has been deprecated :-(. No problem, I am now a technology whiz. I'll just pop open my CRM and click on the client name. Ah, there it is, all of my info on Acme Corporation. There's my list of contacts, all of my marketing letters, all of my communications... wait a minute, where is the info on that project we are doing? Oh yeah, that's right, I need to login to our Project Management System for that... there it is. I wonder how much we have billed this client so far on this project?... umm, where is that information... ah-ha, it's in our ERP, let me login to that. Where is it.... hmm, looking...looking... ah there it is, they misspelled the client name. Wait a minute, this still shows the CEO as Bob, but Bob left last year. CRM shows Bill is the CEO. I am starting to miss Doris. All this technology, and I still have the same problem as before. All these data repositories are the same as the old file cabinets... separate. Suddenly the door busts open and here's this dude in a blue cape screaming "I AM INTEGRATION MAN !". Seriously dude... a cape? "Sorry" he says, and takes off the cape, and sits down and says what I need is to be able to integrate all these silos of data. "Let them talk to each other" he says and I picture my Project Management application hollering over to my ERP system and saying, "Hey ERP!, Bob is out and Bill is in at Acme... get with the program". And ERP says, "oops, sorry, I'll change it so our data matches and I'll also let CRM know when he gets back from the gym". I kick back in my chair and imagine all of my silos of data talking to each other, comparing notes, becoming "one" really, and gossiping about the old metal file cabinet, "those handles are so 70's". I open my eyes and look up to see "Integration Man" putting his cape back on and walking out the door... he turns slightly and I see emblazoned across the back of his cape... "Forceworks".

Power Platform and the Definition of Done

One of the sessions at D365 Saturday Philadelphia this past weekend was "Managing a D365 CE Project" by Jennyfer Hogeland, it was a great session. On one of her slides she described "Definition of Done", and that phrase stuck in my head. Done I don't know about you, but when I hear the word "Done", I assume something has completed. When I am "done" with a meal at a restaurant, they take my plate away, bring me my check, and the wonderful relationship I developed with my server comes to an abrupt conclusion. When the service manager at the car dealership leaves a message on my voicemail that my car is "done", I go down there and get it, and our relationship has concluded, hopefully forever, even though he seemed like a really nice guy. "Done" means something different in the software deployment world. Done times 100 With Agile methodologies, big projects are broken down into smaller parts. Fellow MVP Neil Benson can fill in all the details around this for you, and will probably correct everything I write here. For this post I just want to say, that for each of these smaller parts, there is typically a concept of "Definition of Done". Some people call this "Exit Criteria", which sounds equally terminal. Regardless, if your project gets broken down into 100 parts, you will get to "Done" 100 times. Kind of like when you complete your appetizer, and they take that plate away and put another one in front of you, except it would be a 100 course meal. Done as a Beginning It is not uncommon for a development team to feel they have met the "Definition of Done", only to find that the customer did not understand the definition in the first place. "What do you mean Done? What about xyz...?" It is not that hard to come up with a definition of done that your team understands, it is exponentially harder to come up with one that your customer understands. Their advance agreement is not a reliable signal that they actually understand what they are agreeing to. Why would a customer agree to something they don't understand? Often, it is because they don't want to appear like they don't know what you are talking about. They are content to understand what you mean, after you get there, and then renegotiate if necessary. Done as a Flag in the Ground One of the key advantages to your development team is creating several points along the path where they can plant a flag and say "This thing is done". It should protect both sides from misunderstandings, or at least limit the damage to either party when there are misunderstandings. If we waited until the end of a year-long implementation to say "Done", all of those misunderstandings will be a wave that will wash over everyone involved. Another fellow MVP Gus Gonzales recently did a podcast outlining these very issues using a real world case... case as in law suit. SOWs When engaging an implementation partner, it is quite common to have your discussions conclude with a "Statement of Work". A typical statement of work will attempt to define the deliverables and the costs associated with delivering them. It may have been created pursuant to a list of requirements from the customer, or several pre-sales phone calls or meetings. The lazy SOW says, "We will deliver all of the requirements from your list, which is attached, for $X dollars." A customer who signs off on that is an idiot, and the project is already doomed. A better SOW does not even reference the customer's list, but rather replaces it and covers each aspect, broken into chunks with a "definition of done" for each chunk. But, I would never give a customer one of these either. In fact, we don't give customers SOWs at all. Why SOWs don't work anymore I think SOWs were always a shitty way to create a contractual relationship, but never more so than today. All SOWs are ultimately agreed to at a "point in time". Back in the day, that point remained fairly static throughout the life of the engagement. Not so anymore, not even close. A month after that SOW was memorialized, new features were released that the SOW did not contemplate. Now what, do we continue down the path, or maybe look at whether any of these new features make more sense for one of more aspects of this SOW we are both bound by? If they do, do we both mutually agree to change the scope. Does that change in scope require a change in cost? Are we going to argue over that because you think I have you over a barrel? Am I going to be a dick about that because I actually do have you over a barrel? If we ultimately agree, what are we going to do next month when it happens again? It is little wonder that so many of these relationships turn out sour in the end, or worse, in litigation. Fed Up Several years ago, I got fed up with the broken SOW process. While I never put my foot on a customer's neck, they frequently assumed I was, because I could.  My Dad once told me that, "Leverage always exists, there is no such thing as neutral... who has it at the time, may not be clear". I can certainly recall being on the phone back in the day with customer making all kinds of demands, assuming he had some leverage, when in fact he did not. It is not a good place for the customer to be, and I did not like it either as you may have gathered from my last post. Our Pivot I decided that we were going to take a business risk, by no longer responding with SOWs... or fixed cost agreements. They create an antagonistic relationship from the jump. Our "risk" was whether customers would go along with the idea. We did not invent this idea, but at the time, it was pretty novel in our space, and still is. We developed a two-page agreement, where customers could pre-purchase blocks of time, the larger the block, the lower the rate. What could be done with this "time"? Anything the customer wanted. We also simplified the tiered rate structure into a single blended rate. The whole concept could be digested in about 3 minutes, without the legal department having to look for "gotchas". Many other partners told me that no customer, particularly large ones, would ever move forward on this basis. They were wrong. Since we launched it, we have helped hundreds of customers, including multiple Fortune 500 customers, and the freaking United States Navy. In fact, there as been virtually no resistance at all. Selling Time Blocks I still had many partners not believing that customers would engage this way, being unable to imagine their customers going along. I have also talked to some who said they tried, and had limited success. Compared to our 100% success rate, I decided that this was a sales problem for these partners. I know their customers would go for it, if they presented it the right way. The key point is that every customer who ever did an SOW or "Fixed-price" agreement was not happy with that model either. That trend is getting worse, which can easily be seen by searching for example "Accenture Lawsuit". Not to pick on Accenture, their current woes are just fresh in my mind, but SOWs and Fixed-price agreements are ending in litigation at an alarming rate today. How about instead of going down a path with a high possibility of failure, you instead try something that minimizes the risk to everyone. In our case, the maximum size block a customer can buy at one time is 80 Hours. Why? This means that every week or two, we both get to reassess our relationship. While leverage may still exist, it is more equalized. If you are not happy with us, then you can go another direction, the block was consumed, and we owe each other nothing. On the other hand, if you are a raging asshole, once the block has been consumed, I can say adios. But another thing I have noticed in this arrangement is there is seldom a need for the customer to become a raging asshole. In fact, I don't recall off-hand ever saying Adios to one. Agile-ty This concept dovetails nicely into Agile frameworks also. You can't get much more "Agile" than being able to redirect all energies in a new direction when new features are launched or other realizations are made by the customer along the way. No change-orders to argue over, no hard feelings, the river of effort just flows down whatever tributaries the customer wants it to. Hey, wait a minute "Steve, you seem to be glossing over a huge aspect for partners. Where we make the big money is when we come in way under cost, in your scenario this windfall would not exist!" First, I would say that you need to subtract from your windfalls on the winners, all of your losses on loser projects, and come back to me. If you ever chatted to a gambling addict, all they talk about are the times they won. But, if your winners do vastly outnumber your losers in dollars, then you would be right. This model assumes that your customer will actually get an hour for every hour they purchased. Which, by the way, is a other huge selling point! We obviously generate a margin on each hour sold, but there are no opportunities for a huge windfall with this model. Conversely, it is also impossible to end up upside-down on a project. Since customers pre-pay for the blocks, we also have no account receivable department and zero collection effort. A Win-Win? I think so, if the profitability of your business is dependent on windfalls from winners to offset losses from losers, then moving to this model will help you at least sleep. You can also move from having a few key customers who will sing your praises, to have every customer doing so. This certainly makes getting more customers a lot easier. When your prospect asks for a reference, it feels good to be able to respond with: "Sure, how about every customer we have?". I get that this approach is not for all partners, though I am not sure why. I also get that not all customers will go along, but I have yet to run into one. I am happy to discuss with any partner how we make this work, or any customer who wants to explore it as well.  

Are you brave enough to ask your customers how you are doing?

I am currently in the software consulting business supporting Microsoft's Power Platform. As you may know, I write about it a lot, but for this post I wanted to veer off a little bit from my typical subject matter. Instead I wanted to talk about customers, and their experiences with companies that provide services. Epiphany I was talking to one of our customer-facing people a few months ago, who was working on one of our larger customer projects. I asked him how things were going. He started to go into the customer's asks, and the hours that had been utilized to fulfill those asks. I interrupted and said, "No, I mean, is the customer happy?" He hesitated, then replied, "I think so". My brain started churning, "you think so"? Do we know? I came to the realization that I always know when a customer is not happy, because they don't hesitate to let me know. But they never let me know that they are actually happy... unless I ask them. "Fine" Occasionally, my wife will ask me how something like her new hair style looks. My reflexive response is "Fine", which leads to her stomping off and mumbling, "I know what fine means". Apparently, I do not know what "Fine" means. It seems that it actually means that I am indifferent, which was not her desired response. Whenever I am on the phone with a current customer, I always ask how things are going, and they frequently say, "Fine". Until recently, I took that as a satisfactory response. But actually "Satisfactory", is not a very satisfactory response to that question. "Fine" does not equal "I love you guys!" I think it means they are indifferent to the job you are doing for them, neither dissatisfied enough to get rid of you, nor thrilled to be working with you either. It is a "Neutral" response. Neutral When you put your car in neutral and rev your engine, you go neither forward nor backward. Neutral kinda sucks. While you can know for sure if a customer is not happy with you, you can only intuit whether they are thrilled. But what if your intuition is wrong, and they are only "Fine" with you. Are they going to tell their colleagues about you? Are they going to go to bat for you to stay on the project as it grows or evolves? Or are they going to say, "Eh, they're fine"? Yes, neutral sucks. So how do you get out of neutral? You can Ask Years ago we were brought in by another partner in a P2P scenario to assist with Dynamics 365. I remember some call with me and the partner where he was wondering if the customer was satisfied with things. I said, "Well, we can give them a call and ask?". He replied, "Hell no, don't ever do that!". I said, "Why Not?", and he said, "What if they're not happy?". Obviously I love to hear that my customers are very happy with us, but the value I receive from that is a smile. The real value is received when they are not happy. I don't like hearing it, but hiding from it is worse. At least knowing, I can take action. If the first time I hear that they are unhappy, is when they take the step of reaching out to me, it could be too late. NPS The Net Promoter Score idea was brilliant. It sums up the health of your relationship with one single question: "How likely is it that you would recommend our company/product/service to a friend or colleague?". Respondents are asked to rate that question on a scale of 0-10, 10 being most likely. It is simple, and easy for them to provide, unlike a full Customer Satisfaction Survey. From the web:"Those who respond with a score of 9 to 10 are called Promoters, and are considered likely to exhibit value-creating behaviors, such as buying more, remaining customers for longer, and making more positive referrals to other potential customers. Those who respond with a score of 0 to 6 are labeled Detractors, and they are believed to be less likely to exhibit the value-creating behaviors. Responses of 7 and 8 are labeled Passives, and their behavior falls between Promoters and Detractors. The Net Promoter Score is calculated by subtracting the percentage of customers who are Detractors from the percentage of customers who are Promoters. For purposes of calculating a Net Promoter Score, Passives count toward the total number of respondents, thus decreasing the percentage of detractors and promoters and pushing the net score toward 0." Typical Use I think the most common use for NPS is sending it to customers after they received your product or service, and generating a Score from the aggregate results. I am less concerned about the aggregate score, I am more interested in the individual result. I am also not wanting to wait until the end of the engagement to get it. We instituted a program where we ask regularly, sometimes even weekly, during an engagement. It can be automated. Basically I want to take the temperature of the relationship continuously. Once a week, I may ask a customer for a single button press, so it is not a hassle for them to give it. This is part of the beauty of a single question. Hiring How has this impacted our hiring practices? This seems like a left field topic, but actually it is not. We share the customer score with the team member in charge of the project. What do I consider an appropriate response from a team member for a low score? Well, it does not include things like, "It's not my fault", or "The customer is an asshole", or "It's okay, I'm billing the crap out of them". No, I want people who are on the verge of tears when they hear their performance was scored low by a customer. Their tendencies are fairly easy to spot in an interview. Long Game You can no longer build a sustainable business on the "Burnt Bridge" model. Cloud has moved us all into having to think longer term. The old days of trying to get as much revenue as possible, as quickly as possible, are pretty much gone. The new game is revenue generation over time. How much time? It may take years to generate the same revenue from a customer that it took months to obtain in the past. Needless to say, if you are not keeping them happy, you may not been engaged with them for very long. Your best customers are your existing customers, and the best of those are the ones that are happy with you. So you need to be asking, "Are you happy?". Not being asked? If you are a customer, and your partner has not implemented a similar program of regularly asking if you are happy, you are not out-of-luck. You can probably get a similar result by pro-actively telling them on a regular basis. It might also be a good check for yourself. You can set a reminder in your calendar every week to send an email and tell them, "On a scale of zero to ten, my happiness level with you today is...". Not only will this usually snap the partner into focus, but it will be a reminder to you of whether you actually are happy with them, or not. Big Partners I would not expect any of the Global Systems Integrators (GSI) to take this path, nor would they likely respond to your initiated "Happiness Notifications". Frankly, GSIs mostly suck when it comes to customer satisfaction. They seem to operate more on a "How hard can we screw you, before you sue us" model. There are plenty of examples in the news today, so I won't go into that any further. Faith Moving to a model, for which the most critical metric is customer happiness, even over revenue, is not easy. If actually requires you to take a leap of faith. Faith that if your customers are really happy with you, that will result in more revenue over time. I also am not blind to the fact that some customers cannot be made happy, they simply will not allow it. Since my goal is revenue over a long period of time, when I encounter these customers, and I know they will not allow themselves to be happy, I will refer them to another partner... maybe a GSI:). Since I can't reach my goals with that customer, I am happy to let them do the battling they crave with someone else. What are you doing to protect your future revenue? Let me know in the comments.  

PowerApps - Why Spreadsheets Suck

What a wonderful invention spreadsheets were. For many things, I don't know how we even managed before them. Okay, I do know, because I am that old... we managed things poorly. Spreadsheets solved so many challenges, that they eventually created new ones. 1-2-3 The first spreadsheet software I actually used was called 1-2-3 from Lotus, back around 1985. I created all sorts of spreadsheets, Shortly after, I switched up to Lotus Symphony, which was basically spreadsheet software with a programming language. With Symphony, I built a complex job-costing system for my business at the time. It was really my first experience as a "Citizen Developer". Needless to say, Microsoft eventually launched Excel, and crushed all of the other spreadsheet applications out of existence. For good reason... it was better. Access Microsoft launched another product in 1992 called "Access". It was a relational database product, and also was not the first. Some users of Excel started looking to Access as a way to build business applications. Access was "accessible", and many "normal" users built things on it. While the term "Citizen Developer" may seem recent, the concept has actually been around for a very long time. Although the tools may have changed quite a bit since then, the fundamental concepts are still pretty much the same today with the Power Platform's underlying Common Data Service (CDS)... a relational database. Fast-Forward Before I put you completely to sleep, let's jump ahead about 3 decades, to today. While the popularity of Access has waned, Excel is still very much alive. If I had to guess the percentage of businesses that use Excel.. I would put it at... 100%. It is simple-to-use, requiring almost no training at all for creating basics lists of information, and basic calculations of those items. Excel's use in organizations is ubiquitous and prolific. It is the "go-to" tool for many users, for almost anything. In fact, in enterprise organizations, I would not be surprised if the number of active spreadsheets in use is in the tens of thousands. Even small businesses often have hundreds of spreadsheets. Spreadsheets have become... an infestation. Infested It sneaks ups slowly. A business or department is formed, and there is an immediate need to capture some data. Who cares what it is, there is some shit we need to keep track of now, and the reflex is to whip up a quick spreadsheet to throw it on so it won't get lost. Makes total sense. Maybe we got a contact page on our website throwing off 5 leads a day, probably going to someone's email box. Let's put them on a spreadsheet and save it as "web site leads", and then we'll just add to it as they come in. Forget about web leads, it could be anything, but this is an easy example. So having these leads on a spreadsheet is good... we won't lose them, but we need to act on them. Next step, send a copy to our two salespeople. Today, you could actually just share it with the two salespeople, but copies are still most often the default. So now have someone updating the spreadsheet daily with new leads, and sending it to both salespeople. The salespeople are getting a daily new copy of this spreadsheet, but they have been taking actions on the last one(s). So they create a spreadsheet of their own to track their activities, and just add to it when they get the daily update. The Sales Manager wants to keep track of what is going on, so she asks the two salespeople to send her their updates daily. She then creates a spreadsheet to consolidate the two she receives. So how many spreadsheets do he have now? To be fair, a lot of this could be simplified using a shared spreadsheet, but still a spreadsheet is being used as a database. 95/5 Rule Excel was not designed to be a database, but rather a data analysis tool. The number of capabilities in Excel are staggering, yet 95% of users only use 5% of the capability. But Excel actually looks like a database table... columns for attributes and rows for records... sounds pretty similar. But used as a database, Excel gets unwieldy quickly. Imagine the scenario I described above growing over time to 50 leads a day coming in, and 20 salespeople. In enterprise businesses, I have seen similar scenarios with thousands of people trying to coordinate a business process with Excel. Excel was never intended to do that. Have you done this? I often see spreadsheets that do not use any of the calculating functions. A tab is created for each thing, like a tab for each Customer for example. On each tab are areas for the customer name, description, etc. Maybe even a running list of Phone Calls or other activities. Basically using a Spreadsheet as a quasi-CRM. I can't say this is stupid; CRM systems have become quite complex and expensive, where spreadsheets are more or less free! Tipping Point When are you torturing Excel too much? I don't need to tell you, if you have read this far your Excel-based system is already breaking down. Sally, looking at the wrong spreadsheet, calls a customer to introduce herself, only to find out that Bob called them yesterday. Bill added a note that someone needs to send Acme a price list, and nobody ever did. Joe adds a new Lead to his own copy, without realizing that Mary was already working on it. The fracture points are various and numerous. When did it start? Actually, when the second person was added to the process, the seeds were planted for it's eventual implosion. But CRM is so expensive! Think ROI It's funny some of the rationalizations customers come up with to avoid a cost. I often hear stories of massive inefficiencies costing customers thousands of dollars, followed by, "Is there a way 5 users could share a license"... to save $160! I get it... you are moving from a shit system, but it's free. But is it free? Have you taken into account anything other than a free system vs a system with a cost? SMBs really struggle with this one, focusing 100% on the possible additional cost. Easily able to ignore the costs they are currently incurring like wasted time and lost opportunities, and in a worst-case lost customers. A Path Forward Microsoft gave you the tool to create this mess, and thankfully, they also created the tools to get you out of it. You need a "Business Application" to replace your spreadsheet(s), we both know that. If you are using Excel, you probably already have other Microsoft products, like Outlook etc, or maybe even Office 365, so it makes sense to look to the same company for a solution to your Excelplosion. The main thing is, that you don't want to find yourself down the road with the same problem. Microsoft has a couple of ways to avoid that happening, Dynamics 365 or PowerApps. Let's unpack them briefly. Microsoft Dynamics 365 This is Microsoft's world-class, enterprise-grade Business Application family. If you are an enterprise, it may already be in use elsewhere in your organization. It competes head-to-head with Salesforce.com, and is a very powerful platform for solving the most complex business processes. If you have sophisticated applications in place already and are looking to move to the next level, this is something to consider. But, moving from an Excel-based system, you could not possibly have been solving enterprise-grade problems, so it could feel like a pretty big hammer. It is a big hammer, and if you are reading this post, you should ignore it completely.  Trying to go from 50 Miles per hour, straight to 500 Miles per hour, will snap everyone's neck, and you will be in an even worse place. PowerApps Now we're talking. This is exactly where you need to be going next. It is the most logical step forward from an Excel-based system. It is also significantly less expensive than Dynamics 365, and it's "Citizen Developer" friendly. My choice for moving customers off of spreadsheets is what are called "Model-Driven PowerApps", they are like Dynamics 365's little brother. They sit on the same relational database (Common Data Service) as the monster applications, but without all of the tentacles of complexity. If your needs eventually become really huge, you can easily activate the monster without having to move anything. Back to Access? If you ever worked with Microsoft Access before, PowerApps is kind of like the new version of that, but at the same time, nothing like that. The similarities are that a person with some basic technical skills can build a usable application on top of a relational database. While Access was not specifically designed for non-developers, PowerApps has enabling "Citizen Developers" as a core goal. If you don't have a comfort with basic "techy" stuff, or you don't have the time to mess with it, a partner that specializes in PowerApps can help you get there. Shameless plug: my company, Forceworks is a PowerApps partner, but the army of PowerApps partners is growing fast. Another Shameless Plug As part of our mission to move Excel-based systems to PowerApps, we created an accelerator to help customers get there faster and save some money. We call it RapidStartCRM, and you can learn more about it at https://rapidstartcrm.com. So I think that about covers it, or at least starts the conversation. It's time to stop torturing Excel, and torturing your team... you have officially run out of excuses.    

Common Data Service - Strategies and Silos

So the buzz about the Common Data Service (CDS) has reached a deafening stage. It is the most exciting thing that has come out of the Microsoft Business Applications group in a decade. The possibilities jumped into the category of "endless". So how do you start with something that is endless? Quick Primer I previously wrote about the Common Data Service here, but let's have a quick primer for this conversation. The Common Data Service (CDS) is basically a database that runs under your applications. You can have many applications running on a single CDS, all sharing the underlying data. That is pretty cool. What are these applications? Well, the list is growing, but includes things like Dynamics 365 Customer Engagement Applications, as well as Custom built PowerApps applications. Also, some other apps managed to get stood up on CDS, like Microsoft Forms Pro for example. Via connectors, you can also consume data from over 250 other sources into your CDS environment. Strategies We have what could appear to be an irony here. For the last several years, we partners have been on a mission to eliminate data silos. All of these multiple applications in use with our customers, that not only create similar data in different places, but usually don't talk to each other. There's been a whole lot of copying and pasting going on, which is not only a pain in the ass, but is inherently error-prone. It is not uncommon for an employee to have five applications open to do their jobs, and that's just silly. Part of our mission to date with Dynamics 365 has been to consolidate as many of these disparate applications into a single place. A noble goal to be sure, and a message that has resonated strongly with many customers, who suddenly found themselves sitting on a house of cards. The idea of a "Common" Data Service seems to solve all of that. But Microsoft recently announced some licensing changes, and one of the changes was that you can have as many CDS environments, as you have storage capacity to support. Wait a minute. Are we now promoting silos again? Not Common Think about a restaurant that promotes the "Best Burger in the World"... I want that. You go to get "it" and it's available in 20 variations. So wait a minute, is it the best burger, or the 20 best burgers? You ask the cook which one is the "Best burger", and he says, "it depends on what you like on it, but the beef patty, that they all come with is the best grade beef available". I ask if I can have all of the 20 variations of toppings on one burger... he frowns. But how awesome would that be? One awesome patty, with everything on top of it! Why would I want more than one? Well... maybe because peanut butter and barbecue sauce, while I like them both, don't taste good together? So let's see how I relate this scenario to CDS. Gaining Footing So CDS has been out long enough now for many of us to wrap our heads around it, at least enough to be able to explain it to customers. Now, many of us are actively deploying solutions built on CDS, and we are starting to see the scenarios forming. Scenarios that we had not necessarily contemplated before. For example, I am now being asked questions, that never were questions before like, "For this other department, should we add them to our existing CDS environment, or create a new one?" My knee-jerk response, having been a trained silo-buster, was "add them to the existing environment, or course". But is that always the correct answer? And it if was, then why is Microsoft offering them as many CDS environments as they want? Shared Data Back in the old days, if you wanted two different departments working in Dynamics 365, that did not share any data, you might have used Business Units. Or, sometimes a second production instance was used, but that had a cost. Today, you can have as many environments as your storage will support, so does that change the thought process? Today, my position on this is based on whether there is shared data. If these two departments will be sharing Accounts for example, then my recommendation would be to create a new app for department #2, specific for their needs, but add it to the existing environment. We certainly don't want to have two separate Account tables to deal with. This is the silo busting approach that we have been working towards for years now. So When? When might it make sense to create a separate environment? In my opinion, it is when the users are not sharing any data. This is a frequent occurrence in enterprise organizations in particular. Rarely have I seen HR for example, use any of the data that Sales does. In this scenario, I would take Microsoft up on their offer and spin up a separate environment. Could I accomplish this in a single environment? Yes, but it could get messy, and there is no upside any more. It is hard to completely isolate two apps from each other on the same environment. Changes to one, could potentially impact the other, if you are not paying close attention. Data segregation strategies can also get complex to maintain. Fiddle with a workflow condition for App A, and all of the sudden the records in the App B are doing weird things, if you aren't on your toes. There are a lot of ways to get in trouble if you are not right on top of it... and why bother? Licensing? On the licensing side there seems to be some confusion also, which is not unexpected. Let's say you have a sales team using the D365 Enterprise Sales app, they also have rights to PowerApps. Let's say a part of that team is focused on Lead Generation only, and not Opportunities. Clearly they will share some data, but they have different roles in the process. You can build another app on the same environment targeted to them, and they are already licensed to use it. But let's say H.R. pops up with a need for an app, and they won't be sharing any common data with sales. If those users also have a D365 Sales license, you can spin up an entirely separate environment for them and they can use that. Better yet, if H.R. does not need any of the sales related entities at all, those users could get by with PowerApps P2 licenses and save some money. However those PowerApps licensed users could not use the Sales App. There... that should be clear. Okay, I know it is not clear. Licensing is a tricky thing to navigate, but it is important to understand what licenses you need for what you are doing, or you could easily "over-license". Meaning you bought a license that allows for a lot more than what you need, and so you are paying more than you need to. I have found that Microsoft Support is often clueless to the nuances of licensing, and Microsoft Sellers are motivated to sell the most expensive licenses. Even partners struggle with this one sometimes, so it is definitely not something to figure out on your own. Your best bet is a "licensing knowledgeable" partner, which is also a rare find. I am sure there are other opinions and CDS strategies being used, let me hear yours in the comments.  

Dynamics 365 Business Central - Is it a SMB Solution?

It seems that many people are confused about where Dynamics 365 Business Central fits into the landscape. Is it an ERP... a CRM... is it for SMB... Midsized...Enterprise? Is it part of the Power Platform? At the risk of annoying my BC Partner friends once again, I will take a stab at it. Origins It would be helpful to know the origins of Dynamics 365 Business Central "BC", to understand how it came to it's current position, and then I'll discuss it's current position. Once upon a time, there was a product called Navision that Microsoft acquired. There is more to that story, but that is all that is relevant here. That product, since shortened to "NAV", is still alive and well and in use by many businesses around the world. Several years ago, Microsoft started their shift of Business Applications to the cloud, following the tremendous success of Office 365 and Azure. The first product to make that move was Dynamics CRM, and at the time it was launched as "Dynamics CRM Online". Dynamics CRM was not the only business application in the stable, it was just the first to go SaaS. Other products included Dynamics GP, Dynamics SL, Dynamics AX and Dynamics NAV, each of which were different flavors of Enterprise Resource Planning or "ERP". Enterprise Resource Planning is a pretty vague term. It could include human resources, supply chain management, sales activities and many more, but all of these activities revolve around a General Ledger in an ERP system. GL, AR and AP are the common denominators for each of these systems... and every business must have these components. All enterprise sized companies have an ERP, and most Midsized businesses do as well. Smaller businesses may have a solution like Xero or Quickbooks, that fills this purpose at a smaller scale for simpler needs. Many Midsized businesses are also using these simpler products... some successfully, and some who have outgrown them and are considering an ERP. Darwin Darwin's Theory of Evolution by Natural Selection was not conceived for software. But similar rules apply. Basically the strongest will survive. What was strong yesterday, may not be strong tomorrow as the environment changes, and when previously strong players do not adapt, they are replaced by new strong players. This was what drove Microsoft to the cloud in the first place... seeing other players adapt, and become leaders. So Microsoft adapted as well, and given their war chest, they were able to adapt very quickly to a SaaS model. But along the way choices had to be made. One of those choices was, which ERP solution(s) would take the SaaS path. Shifting an on-premise product to SaaS is no small feat, and requires a significant investment. Having four on-premise ERP solutions, it was obvious that all four would not go SaaS. Microsoft drew a line across their customer base, dividing Enterprise on one side and everybody else on the other, and decided to pick one ERP for each side that would go SaaS. Why not just pick one? Well, I didn't have a vote, but I wrote about that here. Regardless, Microsoft selected AX for the Enterprise and NAV for... everybody else. It was pretty hard to argue AX as the Enterprise choice, but there was some debate about NAV vs. GP. GP is much bigger in the US, but NAV is actually bigger globally, so that decision made the most sense.... unless you were a GP partner. Cloudification I won't go into the cloud journey for AX, instead I will focus on the journey of NAV... which actually starts with CRM. Several years ago, Microsoft had an idea to create a specific offering for SMB called "Business Edition". It would be a scaled down version of the Enterprise CRM solution, better suited for the needs of Smaller businesses. Shortly into that initiative, the decision was made that this would be the best place to start the SaaS journey for NAV as well, and thus began the project code-named "Madeira". Given the SMB target segment, this was going to be positioned as a Quickbooks/Xero competing product. Understand that this was well before the idea of a "Common Data Service" was even on the future roadmap. BTW, another product that got it's start in the Business Edition effort was Dynamics 365 for Marketing. About a year into the "Business Edition" effort, Microsoft decided that the path they were on, was not going to reach the original goals as intended, and the goals had shifted as well. CRM itself was heading down a path of componentizing its parts, and separation from its platform... this ultimately led to what we now know as the Common Data Service. But what about "Madeira" and Marketing? Dynamics 365 for Marketing continued it's journey as an independent application, no longer bound by the "Business Edition" limitations. And Madeira? Microsoft Launches Business Central! Project Madeira, similarly became unbound from the Business Edition limitations, and was launched as an independent application called Dynamics 365 Business Central. There are a lot of side routes that this took that I won't go into here. Today, Microsoft Dynamics 365 Business Central is one of the fastest growing SaaS Business Applications in Microsoft's stable. A far cry from my earlier predictions that it would never see the light of day. Maybe the product owner at the time, Marko Perisic, made it successful just to prove me wrong. Nevertheless, it is on fire. So where did it go? Moving Uptown Once the Business Edition tag was removed, Marko quickly pivoted BC from a Quickbooks/Xero compete, into a product those customers could move up to as they outgrew them. While the CRM side of the house was going through a massive evolution into what we now know as the Power Platform, Marko was able to stomp on the gas pedal. BC was evolving at a faster pace than any other product, partly because it was in a lane by itself. Weekly updates were the norm, and the new northstar became NAV on-premise parity. A goal that I believe has been largely met. SMB might be a fine market, but this thing could go way beyond that... in some cases even standing toe-to-toe with AX for some enterprise customers. So what exactly is BC? What is Business Central? At it's heart, Business Central is a SaaS ERP. "Manage your financials" is at the top of the product's page of capabilities. As you would expect from an ERP it has the GL, AP and AR core functions, but it is much more than that. Like everything Microsoft is doing in Business Applications today, BC is infused with A.I. The next listed capability is "Automate and secure your supply chain", that sounds pretty "enterprisy" to me. Next up is "Sell Smarter and improve customer service", so BC also includes some CRM capabilities. After that is "Keep projects on time and under budget", so we can add some project management capabilities to the list. The last item is "Optimize your operations" for inventory and warehouse management. Clearly this product has grown up quite a bit from its humble "Business Edition" beginnings, and there is a growing number of partner extensions (ISVs) to extend the capabilities even further. The pricing is pretty straightforward, at least in comparison to the Customer Engagement applications. There are only three flavors: "Essentials" at $70/user/month, "Premium" at $100/user/month, and "Team Members" at $8/user/month. To figure out which licenses you need, you can review the licensing guide. You can also sign up for a free trial here. From the Pros Since I am not an expert on Business Central, I reached out to two guys who I know are knee-deep in the product for their thoughts. Andrew King is a Partner at WebSan, a Toronto based Business Applications partner. Since WebSan supports both Dynamics 365 Customer Engagement "CE" as well as Dynamics 365 Business Central "BC", I thought he would be a great guy to contrast the two. Andrew shared that there is some confusion in the market, "The products are as different as Golf and Baseball, but we frequently see customers asking about the product that does not meet their needs. Like BC for CRM needs, or CE for Supply Chain. Would they work? I guess if you like playing golf with a baseball bat". James Crowter is the Managing Director of Technology Management, a UK based Business Applications partner. Technology Management also supports both Dynamics 365 Customer Engagement "CE" as well as Dynamics 365 Business Central "BC", and has a long history with NAV. James talked about the amazing pace of innovation, "I can talk to a new customer in the morning, and have them using BC by the afternoon, which is amazing! For the right customer requirements, BC is a no-brainer... but not for sales workloads, there is not even a workflow capability (for sales), which is a key component for sales!" What Business Central is not? Both Andrew and James agreed that while Business Central is an awesome solution, it is not really a very good Sales tool. Both agreed that they would typically position Customer Engagement for any CRM type requirements, and they often position both products for a true end-to-end solution. They both had some choice words for the Sales Capabilities of BC, and clearly neither one had any interest in activating those, but instead would bring in Customer Engagement for any customers looking to transform their sales processes. So I guess it boils down to, what it is that you are trying to transform. If you are looking to modernize your financial processes, including supply chain and inventory, or have outgrown Quickbooks or Xero... Dynamics 365 Business Central is an excellent option, and you could reach out to Andrew or James for more guidance on that. If you are looking to modernize your sales or service processes, Dynamics 365 Customer Engagement is the clear way to go, and Andrew, James or myself can help you explore that further. But are these the only Microsoft options? Other Big and Small Options If your ERP requirements are really big, and include things like HR management, you might look at Microsoft Dynamics 365 for Finance and Operations. This is Microsoft 's enterprise-grade ERP. Again, we have seen Business Central get into some pretty big businesses, but F&O is the next step up. Conversely, if your sales or service requirements are fairly basic, you may find that Dynamics 365 for Customer Engagement is a pretty big hammer to start with. In that case, you might want to explore RapidStartCRM, our PowerApps based CRM solution. It is an excellent option for small businesses or enterprise departments, built on the Power Platform and running on CDS so you can never outgrow it. Hopefully I cleared up some confusion, but if I actually made you more even confused than before... please keep that to yourself.

Dynamics 365 - The Upsides to the new ISV Program

I recently wrote a post about the coming Revenue Sharing model for Microsoft Business Applications ISV's. As expected, there is some screaming going on about forking over some of your revenue to Microsoft. But there is another side of that story... what Microsoft will be doing in return. Recap Starting soon Microsoft will be moving to a pay-to-play model for ISVs. The first reaction I am hearing from many ISVs are various "avoidance" schemes. Remember, this only applies to SaaS products. Since all of these SaaS products are hosted by Microsoft, and they have all the telemetry they want, you really will be challenged to find a way to avoid Revenue Sharing. It is not an "Optional" program. Though for the time being, you can still "side-load" your solutions, Microsoft will easily discover them. When they do, if you are not part of the program, according to Guggs, "If your solution is not on Appsource, we will tell customers not to use it --- we will get very "pointy" with this message over time". I can't think of any intelligent customer who would not heed this warning, so I suggest you drop your "avoidance" plans. Instead, focus on the promised benefits, and maximizing those. Benefits Depending on where you fall, you have several "levels" of benefits across three buckets: Technical, Marketplace and Sales. I'll share the slide first, and then we can unpack these. Understand that these are subject to change, it is a lever Microsoft can use to increase engagement. Starting Level Let's start at left most column, which is the minimum required "non-optional" option. When you publish a Bizapp solution to AppSource, and you commit to 10% as part of that process, this is what you will get, even without selling anything yet: Architectural Consultation. This is a one-on-one consultation with Microsoft. Unfortunately, you don't get this benefit until after you have published, and it probably would have been handy to have beforehand, but I can also see how Microsoft does not want to waste time with tire-kickers either. Training Vouchers. It is not clear how many of these you get, but without a specific ISV Competency anymore, they don't seem like a related benefit, but... they're not worthless. Customer Surfaced Certification. Seems all solutions will have that by default, in order to even be published. Access to ISV Studio. Ok, now we are getting somewhere.. potentially. We are in the Pilot group to help MS figure out what this can/will be. MS mentions Insights and diagnostics, which are important, and we have been missing that, but I think there is more that can be done behind a name like "ISV Studio". Time will tell, but I would keep an eye on this one. The above are all listed as "Technical Benefits", and you may notice that they are the same across all levels. This is where I expect whatever they are planning to do around IUR will probably be differentiated. Today, the differentiations between levels are really around Marketing, (Sales does not kick in until later), so let's take a look at the minimum Marketing Benefits Marketplace Listing Optimization. This is not "prioritization", it is "optimization", but it is important to understand how solutions are surfaced in AppSource so that your wonderful app is not sitting on page 26. This will include a quick consult with the MS Enablement Team, and will become more programmatic down the road. Think, built-in recommendations against what you have done, surfacing Best Practices suggestions. Marketplace Blog/Newsletter/Social. This should not be your entire "Marketing Program". It is a one-time "blast", but can be quite valuable if you time it right, and amplify it yourself through your own social channels. The $50K Club Once your app has generated $50K USD of revenue sharing fees, which is actually $500K of ISV revenue, in a rolling 12 months, you move up the the $50K Club. This is no small feat, if your solution sells for $10/Month/User, you would need to have sold about 4,200 seats. Again the technical benefits, for the moment, are the same. But you do get additional Marketing Benefits, in addition the the entry level benefits, including: Customer Story. This is a basic customer success story that you can create from Microsoft Templates, and submit for publication here. Again, you will want to amplify this with your social channels, but it is a nice "credibility" builder. Sales Enablement. This is a one-on-one workshop with one of the Microsoft vendors who specialize in helping partners build a sales engine. This goes beyond just AppSource and into your entire potential customers' lifecycle. It seems pretty extensive. P2P Consultation. If you are thinking about selling via other partners, this is a roughly 90 minute consultation on how to approach building a channel. Marketplace Category Promo. At the top of each category in AppSource is a rotating gallery of featured apps. Once you join the $50K Club you will be added to this rotation. I would not expect you to show up more than once, and probably for no more than a week. So again, an opportunity to socialize it and direct customers to it, during the time you are sitting at the top of the category page. Social Selling Coaching Program. I have mentioned socializing several of these things so far, to amplify their value. This benefit is a specific, significant one-on-one workshop to show you exactly how to do this whole "socializing" thing. The $250K Club Once your app has generated $250K USD of revenue sharing fees, you have the option to "opt-in" to the 20% revenue sharing model, but you don't have to. Understand that this means you will have sold $1.25 million USD of ISV revenue, which for your $10 solution, means about 10,500 seats. The air is starting to get thinner here, and the numbers of ISVs in this category will be smaller. But if you do get there, you will not only get additional Marketing Benefits, but you will activate the  Sales Benefits. The additional Marketing Benefits include: Co-Sell Ready Content. As part of the Co-Sell on-boarding process, you will have the opportunity to add to your seller catalog listing, Seller-Facing content, including one-pagers on your company and application, as well as a Customer Story. These are useful for MS Sellers to better understand what you are solving for, and when and where to position your solution with one of their customers. Mini-Commercial. This is a 30 video in this format. You can add this video to your AppSource listing, and of course. promote it through your social channels. PR Support. This would be a Microsoft distributed press release, that could include a quote from a key Microsoft person who would be relevant to your application. Here is an example. Again, you would be advised to amplify this release with your own social channels. P2P Readiness Workshop. For those ISVs planning on building a reseller channel, this is a much deeper dive than the previous P2P Consultation. It is an extended one-on one virtual workshop, and includes not only readiness, but also introductions to potential resellers. Marketplace Home Page Promo. As a member of the $250K Club, you will also get a spot in the rotation in the gallery for the entire marketplace, versus just your category at the $50K level. You will want to double-down on the social amplification of this as again, you will only sit there for a limited time. However, if you are blowing the doors off with your solution, you may find yourself regularly appearing here. In addition, this level kicks in the Sales Benefits, which are the same as at the top level, so I will cover those below. The $750K Club Let's say you somehow sold $3.75 Million dollars of ISV revenue, which for a $10 app, would mean that you miraculously sold about 31,250 seats. I think it is clear that there are only a handful of these ISVs, and maybe not even a whole hand. But you three will also get some additional Marketing Benefits, that include: P2P Workshop - in person. At this stage you will have already had a couple of consults and workshops on channel building. This takes that up yet a notch further as an in-person workshop at your office. This is going to get very pointy on your specific goals and requirements. Secret Shopper. A Microsoft vendor, who specializes in sales motions, will anonymously go through your entire sales process, including any sales doorways. They will come back with frank suggestions on where your sales process is either failing, or could be improved. Tele-sales campaign(s). Most of us are familiar with N3, they are one of Microsoft's key vendors for a lot of things. Working with your team, N3 will craft and execute a telesales campaign for your solution. You can target end customers or resellers depending on where you want to create new traction. Telesales campaigns are notoriously hit or miss. It is probably the most overt form of marketing that there is. N3 has been around the block on this, and will no doubt know better than you how to get the most from it. Global Expansion. If you are kicking ass in your region, Microsoft will be eager, possibly even more eager than you are, to spread your ass kicking solution around the globe. Globalization is more than just flipping a switch in AppSource. You will need to deal with the technical side, like localization, but also the introduction to the regional teams in these new geos that may not have any idea what an ass-kicker you are. Microsoft will facilitate this for you. P2P Lead Gen Webinar. Webinars are another tool for building a channel, and Microsoft will facilitate and promote a webinar for you, under their brand targeted at relevant resellers. You will want to drive additional attendance with your social channels. Seller Webinar. These are fun, I have done a couple of them, including one a few weeks ago. This is an Internal-facing webinar that MS Sellers are invited to. This is an excellent opportunity to talk directly to the MS sellers about how your solution will make them more successful. This is less about customer benefits and more about helping the sellers solve their own challenges. So angle it accordingly. These are recorded and added to a library that the sellers can access for on-demand replays. Sales Benefits Once you cross the $250K mark, and you opt-in to the 20% program, you activate the Microsoft Sales Benefits that include: Prioritized Listing. You can be listed of course without being in the $250K Club. But on the MS Internal Sellers view of the catalog, those that opt into the 20% program will be listed at the top. But it's actually more relevant that the sellers will be keenly aware, that if they sell one of these solutions, they will get paid. This is the primary the reason for the additional 10%... to create the incentives to motivate the Sellers to move your product. Think about something like CPQ where there are a few ISV solutions. While the Seller will be able to see all of them, the ones in the 20% category will have a golden glow around them. Obviously, Sellers are going to move forward with one of those first. Co-Selling Support from MS Field Teams. The field teams consist of AEs (Account Executives), SSPs (Solution Sales Professionals) and TSPs (Technical Sales Professionals). An enterprise level customer may have several SSPs assigned to them for different products, like for example, a specific SSP for Business Applications. Tethered to an SSP is a TSP, and together they are the primary force looking to sell Business Applications into their enterprise customer accounts. It is these SSP/TSP combos that you will want to engage with to bring you into these big deals. This is of course assuming that your solution is designed for enterprise customers. Up until now, they received quota reduction for the value of your ISV solution when they brought you in. That was nice, but it's not the same as money in their hands, which they will get from selling the 20% solutions. This is not a guarantee that your solution will be sold in huge numbers... or at all. For many solutions, this path will not actually do anything. In that case you would have to look to the Marketing Benefits to justify your 20%, or maybe you opt back into the 10% tier. Or maybe you did not see enough value, and never opted into the 20% tier in the first place. Regional Account planning with MS field teams. This one is a two-edged sword. You can work directly with the teams to plan how you are going to pursue targeted Enterprise customers together, which is great. But my experience with Account Planning has been that it also creates a reporting burden on your side. Not an issue if it works. A final point on Co-Selling. Microsoft is aligned strategically to industry verticals. SSP/TSP teams are not only targeting particular horizontal solutions like "Business Applications", but they are also segregated vertically along industry lines. For Example, "Business Applications in Healthcare Sector" would be a specific charge of an SSP/TSP team. In addition, depending on the size of the industry, the teams may be geographically bound also, ie. "Business Applications in Healthcare Sector for US East". Basically, there are a lot of people you would ultimately want/need to engage with. Needless to say, horizontal Solutions and "widget" solutions are probably not a good fit for Co-Selling, as should be obvious from what I wrote above. So this was a long post and I am sorry for that. To add to that, everything I wrote above is subject to change as the program rolls out. It may change a little, or it may change a lot, but as I opened with, this side of the program is a lever that Microsoft can easily adjust. For ISVs that are confused, worried, mad or acronym challenged, I am part of another consulting group called PowerISV with four other MVPs who may be able to help.

PowerApps Component Framework - Frosting on the Cake

I usually wait a week or two to weigh in on new announcements from Microsoft. I like to let the noise die down a little, and see how others are responding to the news. But I am way too excited about the Public Preview launch of the PowerApps Component Framework. What's in a Name? The journey to Public Preview has been a rather long one. Originally coined the "Custom Control Framework" (CCF), which gave way to another name, "PowerApps Control Framework" (PCF), to ultimately landing on the name "PowerApps Component Framework", this "framework" has been quite the work in process. According to the new Branding Guidance, we are not supposed to use the acronym (PCF) anymore, but whoever decided that, does not write blog posts. Good Delays When PCF was first announced, there was a lot of excitement, among the MVP community in particular. We were all eager to get our hands on this new "capability" that was coming soon... but it did not come soon. It was not because there was any lack of will from the team behind it, rather it was another example of Microsoft seeing an "Opportunity". I recently discussed this "opportunistic re-trenching" that has been going on across Microsoft Business Applications on Mary Jo Foley's podcast. The source of this particular delay, was the realization that if both Model-Driven and Canvas PowerApps could share the same Component Framework, it would be way more valuable to everyone. So one step back was taken, to get two steps forward to the Preview. A frustrating delay for some, but well worth the wait. What the Hell is PCF? Is it charts? Is it Kanban boards? Is it Gantt Schedules? Buttons, dials, widgets, cameras? It is actually a way to create all of these, and many other "components". Is it a "Citizen Developer" capability? No, it is not. Building "Components" is a developer-level job, requiring Javascript/typescript and other development skills. For those of you on the development side, this is the future of what you now know of as html Web Resources... but way better. How is it better? Flexibility, portability and supportability are three things that come to my mind of why this is way better. As opposed to building a hard-coded webresource tied to something, with a Component you can package that up with parameters. This means that your Component is abstracted away from the particulars of a specific environment. For example, during the just concluded "Private Preview", we worked directly with the Microsoft development team to refactor a Gantt Chart Webresource that we had built for a specific custom project management entity in one of our ISV solutions. Our original html webresources were of course hard coded to this entity. The finished "Component" version instead included a parameters capability, meaning we could actually display our Gantt Chart "Component" on anything that met the minimum requirements to display it, which in our case was a start and end date. If additional parameters are present such as predecessors, successors or percent complete, it would take advantage of those also... very flexible. We can install our component solution on any environment, and use it wherever we want. While Citizen Developers may struggle to "build" a component, configuring one for their use is completely within their capability. From a supportability standpoint, since Microsoft developed and owns the "Framework", it falls on Microsoft to handle component lifecycle, retain application business logic and optimize for performance... instead of you. Is this All New? Well, it's new to you, but you have actually been using "components" for quite a while, possibly without even knowing it. Remember the fanfare about the addition of editable grids? That was a "component' built by Microsoft on the framework. In fact, a lot of the features you see in the new Unified Interface are actually "Components", including all of the original charts. What is new is your ability to now create your own components. Who will use this? Personally, I think the largest opportunity around the PowerApps Component Framework is for ISVs. Either building components as part of their larger solutions, or even freestanding components that they might resell individually via AppSource. There is some development effort involved, and I don't see a lot of SIs necessarily learning the nuances of building components for individual end customer needs. Better that they just incorporate components that exist, or will exist in the near future. Of course many ISVs still need to get themselves up to the Unified Interface, but that will happen pretty quickly, or they will be in a world of hurt. Are Html WebResources being deprecated? A common question today from customers and partners, whenever the Microsoft Bizapps team launches something new, is whether the old stuff will go away. Everything you are doing will eventually require change. Microsoft can only advance so fast when they are dragging a big bag of legacy behind them. This was the impetus for the One Version strategy. But even in the One Version world, a level of backward compatibility is a requirement... but for how long. How long will Microsoft allow that technical debt pile to grow? As long as they absolutely have to, and no longer. I have not heard anything about deprecating anything as a result of PowerApps Component Framework. But of course the same could have been said two years ago about other, now deprecated things. Neither the future nor Microsoft is waiting for you.

Microsoft steps up to Salesforce’s AppExchange

Let's be real... the Business Applications ISV motion from Microsoft to date, has been a shit show. Many budding ISVs struggled to navigate the program(s) only to reach the conclusion that there was not much there. For all the talk about how important ISVs are, Microsoft's actions to date have failed to live up to their words. I want to personally apologize. The Boy who cried Wolf! I am usually pretty cynical, but over the past few years, I have consistently fallen for the promises from many Microsoft team members, each of whom was independently responsible for some sliver of an ISV effort. Each of them failed to live up to the lowest of promises and expectations. The scattered effort lacked both direction and motivation. Yet, in spite of that history, I continued to get excited about ideas, and shared many of them here with you. If you had taken some of my advice, you to would have been disappointed with the results. For that, I apologize. A Story of Failure AppSource should work... but it doesn't. In Microsoft's zeal to turn it into something big quickly, shortly after it launched, they lowered the bar to entry and it promptly filled up with shit. It remains full of shit as I write this. From apps that won't even install, to some that are downright security risks. Co-Sell should work... but it doesn't. The idea that a Microsoft Seller could actually close a deal faster with an ISV, is not one most Microsoft Sellers have embraced, instead they see ISVs as confusing the conversation and slowing the sale. ISV Competency should work, but Microsoft pulled the pulled the plug on it, only a few months after it was introduced, because they could not remember why the launched it. The very definition of insanity, doing the same things and expecting different results, was fully in-play. The Missing Piece The landscape that I described above, is what Steven Guggenheimer "Guggs" was brought in to fix. Turn this shit show, into a jewel. I previously wrote of my high hopes for this new savior of ISV. Right out of the gate, priority one for Guggs appeared to be, how can Microsoft make money on ISVs. For many, it seemed like adding insult to injury. Seriously, you offer ISVs shit, and now you want them to pay you for that shit! If I were to stop writing this right here, it would not sound very good, but you know I always find the rainbows... Revenue Sharing is Brilliant! Not a novel idea, every other platform has been doing it for years, but Microsoft doing it also, will actually be the best possible thing Microsoft will have done for ISVs. Revenue Sharing is Brilliant? Guggs is no dummy, far from it. He is a no-nonsense kind of guy, that I have gotten know, he was even on my podcast recently. As Guggs surveyed the failures I outlined above, along with the many other failures I did not go into, he spotted the obvious common denominator. He slapped his forehead and said "Holy Crud, we actually don't give a shit!" My dad was my early business mentor, a truly successful entrepreneur. One of the things he would often say in response to ideas that I had was, "There's no percentage in it!".  My dad was not a philanthropist. What he did know, was that without some monetary reward, any business effort would fail. Guggs quickly reached the same conclusion. If you want things fixed, and you want people to give a shit, you need to put a bag of money at their end of the path. Not the only step While reading through the new program documents, it is clear that Revenue Sharing is not the only step Guggs and Team are taking, but it is the only one that matters, and is the single one, that will make all of the other ones happen. It is Pay-to-Play for ISVs now, which may come as an initial shock to many who had gotten used to the free ride. Turbulence Ahead The challenge that Microsoft has with this new effort, is of course, history. For most ISVs, their success has come, in spite of Microsoft. They have learned not to expect anything. I was talking to one of the ISVs that Microsoft often showcases as an "ISV Success Story" today, who told me that Microsoft never gave them anything. No leads, no technical assistance, no sales support, no funding, no... anything. They succeeded completely on their own. It will be a tough sell for Guggs to convince ISVs that they will get a return on this new mandatory cost, and he is well aware of that. Steve Falls for it, Again. The line between "Eternal Optimist" and Moron, is thin. I'd like to think I am the former, rather than the latter. But, up until now, that has not proven to be the case. We transitioned from a mostly SI, to a mostly ISV, because I drank the original Koolaid. Where many of those that did so at the same time, have since abandoned Microsoft as an aid to success, I continued to stay the course, and continued to be disappointed. My gut reaction to the new program announcement was excitement, but then found myself tempering my enthusiasm. Microsoft has also cried Wolf many times. Embrace or Scream The choice of reactions for ISVs will fall fairly clearly on one side or the other. Initially, I expect a lot of them will scream. After digesting the full value proposition, I think a significant number will embrace it. I am embracing it, but I am aware that my credibility on this subject is now dubious. One aspect that I see as key, is with the fact that I will now be paying Microsoft for the privilege of being an ISV for their products, that they "owe" me something. Up until now, the only way to get any ISV help from Microsoft, was to be persistant and super nice and hope that they might throw you a bone for not being an asshole. This "Program" turns the table. In return for my 20% "Payment", (yes, we will be opting into the premium tier), I will be expecting them to step up to the plate, and yes, if necessary, I will be a complete asshole about it. Resistance is Futile For the screamers, I think their screams will fall on deaf ears. I know that some of the bigger ISVs, who like to position themselves as more important to Microsoft, than Microsoft is for them, they will march up the ladder, "You do realize that our solution generates a ton of sales that you would not otherwise see?" This is the anecdotally, hard to quantify argument, that they have leveraged for years. I am sure there is truth to it... but again... hard to quantify. Many of the Bizapps team have proven pliable in the past and quick to buckle under pressure. I don't think Guggs is a buckler, particularly when he knows he is right. "Screw you guys" I'm sure some ISVs will attempt this tactic, but it sounds a little hollow. I mean, where you gonna go? Revenue Sharing is not a new idea that Guggs came up with, it is what the other platforms have been doing all along. In fact, it eerily resembles the Salesforce.com AppExchange model... because it largely is! I would suggest that instead of trying to brow beat Microsoft into some kind of "exception", that ain't gonna happen anyway, you instead hold them to their end of the bargain. I'll go into the specifics in a future post, but based on what I have seen, and been told, if they do hold up their end, this is a no-brainer on ROI, if they don't, you can join me in the asshole club.

Power Platform - CDS Explained for Normal People

There is quite a bit of information in the wild for technically savvy people, around the Power Platform and it's underlying Common Data Service. I want to see if I can make that understandable to us Normal people. Skipping History I know, many of you were thinking, "Ugh, here comes Steve's long, drawn-out 'How we got here' story". But this is for the normal people, who don't really give a shit how we got here, they just want to know if there is something here they can make use of... or not. Platforms on Platforms In a meaningless to you nutshell, the Power Platform is comprised of PowerApps, Power BI and Microsoft Flow, each of which are kinda their own platforms. Each of these is able, but not required, to run on top of yet another platform, the Common Data Service. Additionally, they can be used individually, or in any combination. A well-known example of a PowerApp, would be the Dynamics 365 Enterprise Sales Application built by Microsoft, but you can also build your own. Multi-View Where this fits, and your interpretation of what I am saying in this post, has a lot to do with where you are. If you are currently using Dynamics 365 it may mean something different, than if you are not. For this post, I want to focus on the person who is new to all of this. Multi-Path You have several paths that you can take with Microsoft Business Applications, which one you take, will depend on what you are trying to solve for, what kind of budget you have for solving it, and how sophisticated your users are. Let's crack them open one-by-one, starting with a critical concept. No Cliffs If you have heard this term, and your name was Cliff, you may have thought you were excluded from playing. But what this really refers to is the idea, that no matter where you start, you can keep going without hitting a wall. This is a pretty unique proposition that today, only Microsoft can fulfill. With most other platforms, you will reach a cliff, a point where you can go no further without switching platforms, migrating data etc. Microsoft Business Applications are used by one-person companies, all the way up to the largest companies in the world. There are no gates, you can start with the simplest need, and keep extending, and extending with no limits. You can literally grow from a one-person firm, to a 100k employee enterprise, without ever having to change platforms. No other vendor can say that today. Big Toys We might as well start at the top with Dynamics 365, a set of world-class, enterprise grade applications that deliver an incredible array of capabilities. From Marketing Automation to Sales Force Automation, Project Service Automation and Connected Field Service Automation, all with baked-in intelligence. No other vendor comes close to what the collective Dynamics 365 applications can bring to bear, on the most advanced business requirements on the planet. While Dynamics 365 applications may be the top of the mountain, they are also the tip of the iceberg. Even these world-class applications are cliff-free with the ability to tap into Azure for even more advanced capabilities, or Microsoft Flow, to connect to vast array of other services, including competing services, who does that? Nobody else does that. Small Toys There is a growing number of enterprise organizations that are making the move to Microsoft Dynamics 365, as well as smaller organizations with complex needs. So if you are not an enterprise organization or have complex needs are you out of luck? Hardly. Microsoft has a path for every business. Let's jump to the other end of the spectrum to Micro-Businesses. 1-5, Make me Alive For a micro-business, I am going to first make an assumption that you are already an Office 365 customer. It's not a requirement, but it is a no-brainer, and opens up even more doors. Personally, I think the easiest place to get started with graduating from spreadsheets, is Microsoft Flow, hands down. A no-code solution for activating automated processes in your organization immediately. Microsoft Flow has hundreds of connections to other Microsoft and non-Microsoft services and tons of pre-built templates. From something as simple as grabbing an incoming email, and auto-replying with a Dropbox attachment, all the way through to multi-step, multi-path, multi-vendor processes spanning your entire organization. Remember, No Cliffs. Mid-Size Businesses Personally, I think the best place for a mid-sized business to start is with PowerApps. A low-code way of building simple to sophisticated apps, that are highly specific to your unique needs. If you want a head-start, check out RapidStartCRM. PowerApps can of course leverage Microsoft Flow, to supercharge your automation, all with no developers required. Level Up Once you have started collecting data and information with your applications, you may want to start adding a layer of intelligence over it so you can really get a tight handle on what's going on. This is where Power BI comes into play. Another low-code capability for gaining insights into your business at a level you probably never had before. Make a Pizza No matter where you begin, you can add any of the other ingredients, at any time, in any order, to any degree. Went big with Dynamics 365 right out of the gate? You can easy add a simple PowerApp for some other department with simpler needs. Or the other way around, started with a simple departmental PowerApp, you can easily add Dynamics 365 Connected Field Service to that. Extending Microsoft Flow with a PowerApp, or extending a PowerApp with Microsoft Flow... all possible, and easier than you think. How did this all happen? The big pivot, that really opened up all of this possibility, was the introduction of the "Common Data Service" (CDS). For most of you, this will be invisible, kind of like the engine in your car. But it is this Azure powered substrate that sits under everything I mentioned above, that lets you effortlessly snap in additional capabilities, and provides this "No Cliffs" evolution. While you don't have to even think about it, it is Microsoft's not-so-secret super sauce, that has competitors either worried, or wanting to join the Microsoft Party. Steve the Shill As I re-read this, I am realizing that I am sounding like a Microsoft Stooge. Really it is just my excitement with the possibilities overflowing onto this post, maybe as a result of my recent Summit attendance and an even  further crystallization in my head of the possibilities. I promise, I'll get back to poking Microsoft in the nose... when and if, they do anything that deserves it.