“If you want the rainbow, you gotta put up with the rain.” Wise words from Nick Frost in Hot Fuzz. Was he also doing Power Platform consulting? That movie really resonated with me recently. In recent weeks, I had the opportunity to join an intensive CRM Bootcamp led by the brilliant Bülent Altinsoy.
Taking a temporary step back from the day-to-day work and reflecting on the power of Model-Driven Apps and Power Platform was quite enlightening. So much so, I drew quite a few parallels between CRM consulting and app design. For 2 weeks, I felt like a sheriff in the bustling town of Business Applications.

As you embark on this wild blog post ride, I've rounded up 3 valuable lessons about the world of app design; the 3 D's if you may. Think of them as some essential tools in your consultant's utility belt. Just like Nicholas Angel in "Hot Fuzz", I’m here to make sure your Power Platform adventures go off without a hitch with 3 lessons.
Let’s do this.
You do NOT have the right to remain silent - Design Thinking

The first stage in a new project is to understand the business. Sometimes, there is a disconnect in conversations between pre-sales consultants, architects and BAs. These silos must be broken to speed up the discovery.
Thinking differently: What if you did not just listen to requirements to draft a client proposal? What if you instead used Design Thinking workshops to approach requirements with a Product Manager mindset? Remaining silent and not challenging your stakeholders to review their business model will eventually cost you direction and time when defining the solution.
Key principles to consider: A common challenge is that clients already have an implementation idea in mind without fully comprehending the root cause of their problems.
Consider starting with a one-liner problem statement. Then, create another line to outline the opportunity that comes out of it. Use both as your North Star throughout your conversations. If it does not align, park it so you do not derail. Thus, no blame or shame!
Define the different personas who will be impacted with names and profiles. Your requirements sessions will have a name AND a face to it all. If you are not building for someone and with a purpose, then what is the point?
Combine your earlier statements with the personas to articulate at a high-level what progress and eventual success looks like. That does not mean KPIs straight away as your requirements are not ready. Progress milestones might be easier to envision and communicate to teams. And what better way than using the OKR (Objectives and Key Results) framework, easily supported and tracked by Viva Goals?
Practical tips to get YOU started and the client CONVINCED

Explain to your stakeholder that understanding their business is your priority. This can include a Mural session with the Product Requirements template (see here) or the fishbone template (see here). For more details on Design Thinking and Mural, see this blog post.
"The GREATER Good" of Data Modelling
Let’s be honest. For every business, data is the lifeblood. We need to organize its chaos and reign in it. Bear in mind that this is also an investment for onboarding any Copilot product. Both in terms of the GenAI outputs and the security of your data altogether.
A rule of three will set you free: Don’t let the existing data hierarchy chain you down. Of course, it is important to review and consider. But ultimately, once you have defined your problem and opportunity statements as well as key personas, aim for what is right. Not just what is existing.
Key principles to consider:

Stay on mission your out-of-the-box friends as it comes with perks like ease and speed. In practice, it also means inheriting existing columns, relationships, views, forms, and processes. Sounds tempting, doesn’t it? Whilst clients will naturally want everything customized, that does not preclude leveraging existing features. Just because you have painted the box blue with glitter, it does not mean you did not purchase a white box from Costco. However, let’s remember that licensing is an important factor to consider. For example, if you only have a Power App Premium, you cannot copy the OOTB Dynamics 365 features and use it in your own model driven app as is. That is however a longer and different topic altogether.
Keeping it simple is a sign of strength not weakness. Whilst customization is such a buzzword, having a minimalistic data model is not a cardinal sin. I am not saying do not satisfy requirements. But ultimately, having 50 tables to create little data universes everywhere is excessive. It will complicate your build, probably confuse your relationships, and may also store unnecessary data.
Do you even need to store the data in Dataverse? I know, how dare I question it. But hear me out. Storing the kitchen sink and more of business-type data is not always a big help. From impacting your allocated storage, to auditing taking its toll with performance, or even GDPR-like breaches, sit down with your stakeholder and challenge it a bit. Firstly, is there a need to store certain (new) type of data like date of birth or address? Do you have a compliant data strategy following local and industry compliance standards? Secondly, does that data exist anywhere else? If so, maybe worth considering whether mixing up some virtual tables could be an interesting middle ground.
Practical tips to get YOU started and the client CONVINCED: If you are doing an audit or value assessment of an existing implementation, you can find and review how complicated the existing data model is with a cool tool in the XRMToolBox called “Entity Relation Diagram Creator”. There is a lot to customize there e.g., choosing a language, showing hidden solutions, hiding unpublished customizations, export to draw.io etc.
"Danny's Notebook" of Documentation

When was the last time you were blown away with good (OR ANY) client documentation? Could be on the current architecture, environment governance or even user training. Sometimes it truly is a ghost town out there, and it feels like no one is speaking the same language.
Thinking differently: Start by asking your stakeholders what is available. Ask and you shall receive they say. It plants a seed that documentation matters. And if there is none or none that is satisfying, it is a conversation starter. You can educate them on its importance, where to start and what matters in terms of best practices. Michael Roth has loads of awesome tips on governance, which you can read here.
Key principles to consider:
Requirements are a great point to start your journey of role-modelling good documentation. Do not just use plain emails and Word documents. Explaining features out of requirements is a type of storytelling. Depending on your audience, flex your style by leveraging Power Point to present with impact e.g., if you are playing back requirements to senior leadership. Mission statements, user journeys and a value measurement framework will paint a clearer story of why YOU and YOUR TEAM are the right partner in crime.
As you design and build, keep detailed records of your configurations, workflows, and customizations. Do not leave it until the last minute, and use simple language throughout. There are many places to add these notes in. It can start with clear descriptions in columns, good titles in each step of a Power Automate flow or notes in your VS code to communicate to other devs why you chose a specific solution.
Change Management should be at the top of your documentation game. The way you handle how you communicate with users, train them or create champions out of them in early testing matters. Ultimately, this is how you build early adopters who are excited about what you’re building. Also, this supports easy troubleshooting and onboarding for new team members.
As we wrap up, remember that conquering Power Platform applications is a journey, not a sprint. Embrace these lessons, channel your inner Nicholas Angel, and watch your CRM town transform into a well-oiled machine. So, gear up, customize your sheriff's badge, and let' s make the Power Platform a safer place for all!
Great post! Unfortunately, but understandably, XRMToolBox is not always allowed to be used by the client. So, in that case many nice tools like the ERD Creator won't be available.
I can add one "D": "Don't go back". Planning and understanding data is an essential task of a CRM implementation. A mistake can force you to go back to what you did already and it can create a bigger workload than initially plan. So, this could be more of "you DO NOT WANT to go back" :-)
-Giulio
Bravo great content and fun to read! 👏🏼👏🏼👏🏼