Category: Blog

Sarav loves Samsung Phones and Salesforce. When we asked him for content around product rules, he created this really simple video! We loved it. Hope you do too!

We all know Salesforce is an incredible platform for managing sales operations. Opportunity Stages define an organization’s sales process. In this blog, we are going to calculate the time taken by an Opportunity stage till it reaches the “Closed Won” or “Closed Lost” stage.
This functionality plays a crucial role in Pipeline management. This reveals information on how long it takes for salespeople to advance through each Opportunity stage.

New Opportunity Records 

We can record the Opportunity Stage Change dates for new records using FLOWS. 

Step 1: Select “Record-Triggered Flow” in the “New Flow” pane and click “Create”.

Step 2: Choose an “Opportunity” object and set the trigger condition to “A record is  created or Updated”.

Step 3: Add a decision element. Create separate outcomes for Opportunity stages for which we need to calculate the duration till it reaches “Closed Won/Closed Lost”  Stage,

Step 4: Create test fields with the datatype “Date” for tracking the Stage change dates in Opportunity. 

Step 5: Add an Update triggering element for each stage and map the Current Date to the test  field created in step 4. Mapping “Negotiation/Review Date” to Current Date,

Flow

Finally our flow looks as shown below,

Formula Field Creation

Step 6: Using formula fields, we can proceed with calculating the time taken from each Stage until Closed Won/Closed Lost. 

For calculating the time span between the “Initial Engagement Date” and “Closed Won  Date”,

Calculating the duration between “Initial Engagement Date” and “Closed Lost  Date”,

Please use “Opportunity History Report” to record Stage Durations of existing Opportunity records.

Demo 

Please watch this video that demonstrates the above process.

TL;DR – Just look at the post image to help you talk the right amount in meetings.

We – humans – love to talk, that’s in our genes. That’s how humans evolved to become one of the most innovative life forms – by passing information between our tribes, our friends, and our children. One thing we have less though is the time!

It’s the most important currency for all of us and we get annoyed when we don’t use it properly such as binge-watching a show on Netflix or when someone else hijacks our time by inviting us to an “emergency” meeting. As you might all agree, meetings are the known villains in the corporate world, but no one can stop this supervillain (which I don’t think they all are, but that’s for another post). In fact, if you search on the web, you will find numerous stats about meetings – one such page says that nearly 55 million meetings are held per week in the US alone. 55 Million Meetings!

Despite the time sink these meetings cause, we forget about this annoyance as soon as we are in a meeting. We start talking immediately. We do love talking, don’t we? We talk about how smart we are, how time-pressed we are, and how important the work we are doing is. We talk about the weather, kids, pets, traffic, holidays, bad networks, and everything else under the sky.

Many experts started to notice this trend and recently, as a result of this, there has been a lot of focus on reducing the time we talk and increasing the time we listen. You would have heard one of the many quotes upon this idea such as ‘You have two ears and one mouth, so listen more and talk less.’ – all of which I agree with. There is a lot of value in listening; both from a getting work done perspective and from an empathetic perspective.

But, does that mean talking is all bad, especially in meetings? Yes and no! Let me explain!

Before I started writing this post, I was reflecting on the numerous meetings I have attended in the last few years. I was trying to see if I could come up with a way that people could use to categorize meetings and identify ones where we need to talk less, and the ones where we need to talk a bit more.

The idea here is not to oversimplify meetings but to provide a simple mental model to remind ourselves about our objective for the meeting. So in this blog, I present the l’Sup model!

You will see a simple graph below which visualizes this model. The fun meetings and social get-togethers don’t fall under any of these categories. Let there be no restrictions in those meetings provided you’re amongst your friends or family!

No alt text was provided for this image

In this model, I group the meetings into 4 broad categories:

• Learn meetings – Your objective is to learn from these meetings. You are there to learn about one of the following: a concept, project status, or a new skill.
• Steer meetings – Your objective is to give proper directions to your colleagues around a certain project or initiative. You are there to listen and provide steer with utmost clarity.
• Update meetings – Your objective is to provide updates on something you’re working on, and answer any questions. You will also need to capture any feedback coming out of these meetings.
• Present meetings – Your objective is to present a topic to a large set of audience – a keynote address can be a good example

On one end of the spectrum, we have the dark green learning meetings; on the other, we have the lighter green present meetings.

There is a reason why I used shades of green in the above line – to convey the point that talking is not all that bad.

For example, in an update meeting, you need to talk to ensure the sponsors and stakeholders are aware of what’s going on in your initiative. If you don’t do that, people will lose confidence in the initiative because they don’t know the latest updates and changes. At the same time, if you talk too much as a sponsor in an update meeting, you don’t give an opportunity for the project lead to give a proper status update. As a sponsor, this is a meeting where you have come to learn about the status. Now I hear you say, this is all complex.

I present you the l’Sup Model, see the blog post image, this is a simple line graph really. The X-axis tells you how much you should talk and Y-axis lists your objectives from those meetings. As you see, not all meetings will need stone-cold silence from you.

You can use this model as a compass to decide how long you want to talk in a meeting. The key thing is for you to decide your objective at least 5 minutes before the meeting. Here are some tips to make this model work for you.

Let’s say you’re someone who would like to express your thoughts, the minute you think about it. Have a notepad, write that thought down and wait!

If you are someone who doesn’t like to talk in meetings but have an update meeting. Plan ahead, prepare the slides, and pre-empt the questions.

Remember, if you’re in a learn meeting and you’re in a leadership position, prioritize the questions you ask. In my experience, this automatically reduces the time you talk.

You can also use the famous Bezos meeting rules too.

In summary, talking is not all that bad in meetings if it is inline with your objective for the meeting and you can use the l’Sup model as a compass for your meeting. This is just based on my experience observing meetings generally. You can use this as a mental heuristic to remind yourself about your meeting objective and talk time before the meeting.

Talk the right amount and prosper!

I am often asked the question on when someone should use Agile to deliver Salesforce and Data Projects; I could go the typical consultant way and say: ‘well…it depends!’ – but of course, I don’t want to do that! However, before I could either give you the answer or a framework to approach this question, we need to look at a few aspects of it. If you’re an impatient person (trust me, I was one!), wait till the next article on this topic, I plan to summarise a matrix which can guide you.

Now, let’s get back to the topic!

I am assuming you know what Agile and Salesforce are, but if you’re not familiar with either of them, please click on the links which provides a good summary and have been page ranked well by Google too. 🙂

I hope you made it back to this article without vanishing into a Wikipedia or a Youtube Rabbit hole! Nevertheless, let’s begin by using a scenario to explain this topic easily.

Scenario

Imagine you have taken up a new role in Acme Inc as the Salesforce Programme Manager. Acme Inc has a lot of impatient stakeholders – I mean what are the chancesD!? They would like you to hit the ground running with a Greenfield Salesforce project that also involves large scale data migration. The CTO asks you the million dollar question – do you think we can get this done in 6-8 sprints? This is your first meeting with the CTO and obviously you would like to make a good impression, I get that!

You carefully drink a sip of your coffee from the vending machine and gather your thoughts (As a side note, you’re mildly annoyed that the machine creates a lot of waste for making one cup of coffee!).

Firstly, the CTO has assumed that this project will be implemented using an Agile methodology. Your job is to validate this assumption. Any seasoned Project Manager like you will have the knack of buying a little time before coming up with a more informed response. You know that very well, so you respond to the CTO by saying that from your experience 6-8 sprints are enough to deliver such projects, but… you saw a few requirements which may need some further looking into. You carefully dodge that bullet without introducing that anchor bias around 6-8 sprints.

The key is to have a long pause after that ‘but…‘ which is dramatic enough for the CTO to notice.

The Next Steps

You’re thinking about the CTO’s question as you walk back to your desk with your brand new laptop from Danny – the IT Lead. You assure yourself that you know well about the framework to choose between Agile and Waterfall – the Stacey Matrix, and have used it in your previous projects.

You’re discussing about the question with Ed, who’s a curious Salesforce Project Analyst sitting next to you. You have just met Ed, but he’s not shy of asking questions. He looks at you and says, ‘What the heck is a Stacey Matrix?’ You patiently explain to Ed that the Stacey Matrix is a way of looking at management strategies to solve complex problems.

You say: “Firstly, you classify the problem into the following buckets- Simple, Complicated, Complex and Chaos. You do this based on 2 factors:

• uncertainty on what needs to be happen to solve the problem
• uncertainty around how it should be implemented.

The sweet spot for Agile are the problems which fall under the Complex category. These are projects in which you roughly know what needs to happen to solve an issue – but require feedback to solidify the design. In addition, you don’t know how to implement the full solution.”

Ed is not convinced, and he asks you to explain it using the Salesforce project you’re about to do. You love a good challenge as it improves the quality of the outcome, so you ask Ed a few questions, in an effort to do an initial classification of the project based on Stacey Matrix. Ed knows a lot about this project, as he has been a part of the initial discovery exercise.

1. Is this a Greenfield project? i.e. Are we planning to implement a brand new Salesforce instance?
2. Does it involve large scale data migration?
3. Do we to integrate Salesforce with any other applications?
4. Are the stakeholders open to using Salesforce’s out of the box features? Do we expect them to ask for big customisations?
5. Can we use release some features of the Salesforce quickly to a set of users? As an example, the sales team can start using the Lead to Opportunity functionality for new businesses straight away?
6. Do we have a strong Salesforce Product Owner and Scrum Master in the team?
7. Is the CI/CD pipeline working efficiently?

You ask Ed the above questions, to which he says that he must attend a meeting now, but he has promised to come back within an hour with responses to these questions. Meantime, I suggest you set up your new laptop and schedule that meeting with the CTO to provide an update on the timeline ;-). Good luck!

We will cover the responses and whether we can do this project using Agile methodolody in the next part- feel free to add more questions while we are waiting for Ed to come back from his meeting!

References

1. Stacey RD. Strategic management and organisational dynamics: the challenge of complexity. 3rd ed. Harlow: Prentice Hall, 2002.
2. Dinnie Muslihat. (2018) Agile Methodology: An Overviewat: https://zenkit.com/en/blog/agile-methodology-an-overview/ [Accessed 02 Jan. 2021]