What Is Salesforce and What Does It Do

What Is Salesforce and What Does It Do?

Wish to stay updated with the progress of your sales personnel, revenue generation and the number of sales made by your best employee? Well, you need a CRM and companies are spending $40 Billion on CRMs every year. A CRM is your most reliable companion to store and access customers’ data and establish relationships. Salesforce has set the stage for the CRM industry and one know that it’s worth $120 Billion, shares 20% of CRM market, and 83% of Fortune 500’s companies are using it. Salesforce organizing your customer relationships as it works in the cloud and accessible across platforms.

Before personal computers in the 1980’s, it was the era of Rolodex to store data and market through direct mail/telemarketing. The concepts of digital contact management services and Database Marketing emerged with the birth of personal computing. In the 1990’s businesses moved on to find a unified solution where the management of contacts, tracking the task and reporting would be incorporated altogether to automate the sales process. Some called it SFA and others named it as CIS, ECM, and so on.

Why Every Business Needs A CRM


Storing the sales data and customer relationships is essential for a business. If you’re a small business, you can work out of spreadsheets. However, when your business grows up, you’ll need a variety of complex features that you would hardly get in any spreadsheet. This is where CRM comes into action to rescue the businesses. 
CRM, especially Salesforce, minimizes errors by making corrections automatically and users can sync data on phones and email with no worries. On the top of that SOQL empowers you to make the best use of this powerhouse.
Many businesses think CRMs bring value to their business but are boring at the same time and it’s difficult to get sales teams to use it. However , the opposite is true for Salesforce!

What Makes Salesforce so Unique?

Every business has exclusive and special requirements. What businesses love about Salesforce is, its flexibility. Not every CRM works like Salesforce, rather they try hard to fit every business into their pre-designed CRM. Just like a database, one can create new tables in Salesforce with custom columns and relationships. Like a front-end framework, Salesforce allows you to create a customized UI and layouts. Unlike a database, with Salesforce you can do this and you don’t have to write any code. Salesforce also has a very open API set which makes integration with cloud accounting and marketing systems easy.

Salesforce Apps & Development

Salesforce is alike AWS Lambda as you can produce random code to activate it with Salesforce API however, unlike Lambda, this code can be activated automatically. 
Salesforce is not only a CRM rather it is a platform to build CRMs. In fact, Salesforce makes an administers’ life a breeze considering the convenience of point & click functionality of database editor as well as UI builder with drag-and-drop feature.
Configuration of Salesforce-Platform of Vanilla is more than easier and AppExchange is already there to offer flawless performance through plug & play apps. For highly personalized features, Apex allows developers to make changes through custom code.

History Speaks for Salesforce


Benioff served Oracle for a decade, keenly observed the trends in Customer Software Apps moving towards easiness but he wished to bring something better to Enterprise Software. He established a new company with the name of “Salesforce” and this is where Saas came into being. Considering the complication and cost of software, Salesforce opted the slogan NO-SOFTWARE. After the six years of launch, Salesforce became the pioneer while introducing the premier “App Store”.

Benioff describes Steve Jobs as the best mentor he could ever had. Salesforce’s direction was totally changed based on Jobs’s advice to Benioff about building an “Application Economy”.

Salesforce launched AppExchange in 2005. Entire companies such as FinancialForce.com have been built to develop apps using ExchangeApp. Benioff named it as “App Store” but kept the metaphor of “Exchange” after analysis and market research.

In 2008 PaaS came into existence when all these apps were brought together into Force.com. It brought ease for developers to develop, distribute and sell their apps with Salesforce’s approval. Salesforce Marketing Cloud was launched in 2012, Einstein Analytics in 2016 and a new era started for Salesforce with the launch of Salesforce Health Cloud. 
Their slogan “The End of Software” referred to the basic model of the Enterprise Software, which means to box, marked and sold through sales personnel. Now, they are successful in introducing a novel change how software apps are built, distributed and fit in to serve the purpose across the enterprises.

Should You Be Using Salesforce?

That depends. There are thousands of CRM’s out there. From “One Page” CRM’s to complex interwoven CRM’s that use AI and machine learning to help move your pipeline forward. The real question is “Can your organization use all of Salesforce features and tools?”. If you have a 2 person company selling $5 dollar widgets, Salesforce is a little overkill. If your an organization with a long and complex sales cycle and a large sales team Salesforce is your answer.

Caution

Don’t make Salesforce into something it’s not. “SalesForce was designed for marketing, sales, and campaign specific functions. Spending time, resources and effort trying to make Salesforce into something it wasn’t designed will always turn out to be a disaster.

carlbjohnson-what-exactly-is-a-product-owner

What Exactly is a Product Owner?

Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Product Backlog.
  • Clearly expressing Product Backlog items.
  • Ordering the items in the Product Backlog to best achieve goals and missions.
  • Optimizing the value of the work the Development Team performs.
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
  • Ensuring the Development and Design Team understands items in the Product Backlog to the level needed.
  • Work with Business Analysts and Business Users to ensure features not being created in a vacuum.

The Product Owner may do the above work or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

If you’re not sure who the product owner your project is bound to fail.

Implementing Compliance and Governance with SharePoint

Implementing Compliance and Governance with SharePoint

Over the years I’ve seen some pretty bad SharePoint implementations. Some was the fault of the consulting company, some was the fault of the organization. Each of the implementations had the following in common:

  • Unrealistic Goals and Requirements (too much, too soon)
  • Limited Budget
  • Jack of All Trades , Master of None Consultants
  • Lack of Corporate Involvement
  • Lack of Corporate Communication and Adoption
  • Undefined Governance Plan and Strategy

In “Implementing Compliance and Governance with SharePoint” I discuss how to take SharePoint serious as an organization and design a governance plan that is aligned with your corporate governance and compliance plan. Each chapter provides real world solutions on how to resolve SharePoint’s security and governance shortcomings. Implementing Compliance and Governance with SharePoint will be available for purchase and download in March 2015.

Table of Contents

  • Contents
  • About the Author
  • Acknowledgements
  • Chapter 1: Introduction
  • Chapter 2: Aligning SharePoint with Organizational Goals and Requirements
  • Chapter 3: How to Create a Successful Governance Board
  • Chapter 4: Auditing your Current SharePoint Permissions
  • Chapter 5: Understanding Document and Record Compliance
  • Chapter 6: Aligning SharePoint with your Data Loss Prevention Program
  • Chapter 7: Developing a Strategic Governance Project Plan
  • Chapter 8: Building a Successful Training and Communication Program
  • Chapter 9: How to Get a Grip on your SharePoint Environment
  • Chapter 10: Building a SharePoint User Adoption Plan
  • Chapter 11: Repair Damaged Credibility and User Moral
  • Chapter 12: Understand SharePoint Search
  • Chapter 13: Protecting Documents and Records with Rules and Permissions
  • Chapter 14: Understanding Digital Signatures and Document Encryption
  • Index

It’s a simple fact that, even on non-agile teams, groups that don’t share what they know and learn openly will fail. Software development, despite what most people think, should never be a single person focused on a single task. One person cannot know everything and so cannot produce the software quality that multiple minds can bring together. So, to share some of what I’ve learned in my career in agile management, here is my short list Don’t Assume Even if you think your team is communicating, don’t fool yourself. There’s always places to improve – look for them and vet them out. Be sure that everyone’s talking to everyone they need to and that all blockers are being communicated. Voice isn’t enough Sometimes it takes more than a conference call (especially with remote workers) to get the point across. The web is full of collaboration technology (like Zoom, Skype or Google Plus hangouts) that can help get your point across in a more visual way. Grab a webcam, point it at a whiteboard and go to town. Set plans in stone When you come out of your planning meetings, you should accomplish at least one thing – having everyone on the same page when it comes to where the project is headed. Everyone should know what parts of the project they’re working on and how much time they must do it in. Unfortunately, I haven’t quite found the right groove for this one and have had to play catch-up after the meeting to get people headed in the right direction. These are just a few on a list of many I’m sure I’m forgetting, but hopefully they’ll serve as a reminder to myself (and maybe others) for future planning sessions and projects.

Best Advice For Agile Team Communication

It’s a simple fact that, even on non-agile teams, groups that don’t share what they know and learn openly will fail. Software development, despite what most people think, should never be a single person focused on a single task. One person cannot know everything and so cannot produce the software quality that multiple minds can bring together. So, to share some of what I’ve learned in my career in agile management, here is my short list.
Don’t Assume
Even if you think your team is communicating, don’t fool yourself. There’s always places to improve – look for them and vet them out. Be sure that everyone’s talking to everyone they need to and that all blockers are being communicated.
Voice isn’t enough
Sometimes it takes more than a conference call (especially with remote workers) to get the point across. The web is full of collaboration technology (like Zoom, Skype or Google Plus hangouts) that can help get your point across in a more visual way. Grab a webcam, point it at a whiteboard and go to town.
Set plans in stone
When you come out of your planning meetings, you should accomplish at least one thing – having everyone on the same page when it comes to where the project is headed. Everyone should know what parts of the project they’re working on and how much time they must do it in. Unfortunately, I haven’t quite found the right groove for this one and have had to play catch-up after the meeting to get people headed in the right direction.
These are just a few on a list of many I’m sure I’m forgetting, but hopefully they’ll serve as a reminder to myself (and maybe others) for future planning sessions and projects.

10 ways to improve your backlog

10 Ways to Improve Your Product Backlog

Your Project Requirements and Backlog Should Align
Sometimes the project requirements makes one appearance – at the beginning of the project. Your product backlog and user stories should be a breakdown of your project requirements. Your project requirements should be reviewed almost as much as your product backlog. Teams, priorities, and goals change in the course of a project. Your project requirements should be the foundation, not the product backlog.

Use a Product Roadmap as A Guide
Think of your backlog as your requirements to build a bridge. You can’t build a bridge if you haven’t planned what to do once you reach the other side. Your product backlog should be based on your approved product roadmap. If you have a backlog, but no product road map than you just have a task list.


Always Be Grooming
Sometimes items get into your backlog that doesn’t belong there. Maybe a stakeholder brought up a stakeholder in a meeting and it made its way to the backlog. Refining and prioritizing your backlog will keep it fresh and adjust to business needs.

Recap Backlog with Stakeholders
Because Agile and Scrum are always changing its easy for verbal conversations to be forgotten over time. The last thing you want if to spend 30 hours building a feature the client doesn’t remember asking for. Constantly review a high-level backlog with your stakeholders. In the recap focus on the business reason of “why”, focus less on the “how”.

Write Better User Stories
Most user stories suck. That’s because the person writing the user stories doesn’t understand the business well. Instead of writing user stories in a vacuum ask for a “User Story Session”. Invite the stakeholder and write or rewrite a few user stories from the backlog. This activity should be done in person with a whiteboard.

Less Meetings More Collaboration Sessions
True collaboration is in person. This is not always possible because teams are not located in the same building, state or country, but whenever possible have collaborated. Collaboration and meetings are two different things. The word “meeting” sometime drums up a negative meaning to it. Collaboration Sessions should be fun, interactive, fruitful and have a purpose or goal in mind.

Prepare for Product Backlog Meetings
Don’t prepare for your backlog meeting 10 minutes before the backlog meeting. Instead, print out your backlog and take 10 minutes out of your day marking it up with questions, suggestions, and ideas. One the day of your backlog meeting categorize your questions, suggestion, and ideas into bullet points. You’ll look organized and prepared.
Organize Your Backlog by Groups of Features
Your backlog should have a purpose and releases should bring you closer to solving your customers business challenges. “Picking the low hanging fruit” and “stating with the easier stories” is not necessarily the best way to clear a backlog. If we are building a car, putting in seats is a lot easier than putting in an engine, but are you going to do with a car without an engine.


Wireframe Whenever Possible
I’m a big fan of visuals and wireframes. They help everyone understand the “what”. Without visuals, it’s like giving directions in the dark. It’s possible but requires way more energy. Wireframes and visuals are a tangible representation of what the stakeholder wants. The wireframe can be on the back of a napkin. I prefer to start with a piece of paper and when I have everything drawn out switch to a wireframing tool. The extra time in the being will save you time in the end.

What are some of the challenges you have with your backlog? Feel free to vent in the comments section.

carlbjohnson-blog-post-titanic-project

9 Signs You Are on A Titanic Project?

It’s pretty simple to find out if you’re on a titanic project, they are having the same warning signs. I’ve worked on a few, but 1 sticks out the most. It was an interesting position. Instead of being in a position of management and change prompt change, I was SME with little to no ability to steer the ship away from a certain ice burg. On this project, you had a client that did not understand basic SDLC or Scrum processes and was not open to any sort of criticism. Like the Titanic, everyone around the client is warning their is an iceberg ahead. Instead of coming up with a better plan, the team is told “full speed ahead”. Here are some of the signs you are on a Titanic project:

  1. No or very little senior or executive stakeholders – Big or small, every project needs an executive or senior stakeholder.
  2. Everyone is afraid of the client. – If bringing challenges to the client’s attention can earn you a pink slip, you are on a Titanic project. Communication is essential to understanding the changes and challenges. Without the ability to address issues openly and honestly you are heading for certain failed
  3. So much gold plating you can build a mountain full of gold. – This is connected to #3. You say “Yes” to whatever the client asks for, even if it has nothing to do what’s currently on your planned backlog.
  4. No clear direction of the product – If it takes 4 paragraphs to explain what the product should do you are on a titanic project.
  5. Endless budget – Some organizations, especially in Federal tend to have larger budgets which also means very little oversight. This is a disaster. The advantage of having an oversight committee is making sure the budget doesn’t get out of hand and for teams to focus more on releasing a usable product.
  6. No clear titles – Who is the Product Owner? If the answer is “We don’t have one” You are on a titanic project.
  7. The client too close to the scrum team and product. – The client role should be an SME. If your client is acting like a developer and making page layout changes on the fly, developing workflows and filters and asking you to push it to products, you are on a titanic project. Granted, your client’s feedback is important, but that doesn’t mean they can make changes outside of backlogs and whenever they have a new idea.
  8. No set and respected milestones – One thing Lean teaches is to launch quickly and with customer value in mind. If you’re being asked to develop without setting up milestones, your own a titanic project.
  9. No documentation – Documentation is required for everything. If your project has little to no documentation it’s the same as traveling without a GPS.
carlbjohnson.com-sox

Hello, New CIO, Do You Understand Sarbanes-Oxley?

As a CIO of a financial organization, you have a great deal more to think about beyond just asset management and document management. Your main concerns include keeping your organization’s data safe and navigating the rules of Sarbanes-Oxley (SOX).
SOX is not the new kid on the block; legislation passed it in 2002 in response to notorious accounting scandals at WorldCom, Enron, and other public companies. It was instituted upon the premise that if we could ensure the quality of corporate financial reporting based on secure internal controls, we could enhance the integrity of our records management and financial system. SOX ushered in a number of new requirements for company management and boards as well as for the accounting profession. Among the more noteworthy aspects, per Section 404 of the Act, CEOs, CFOs, and CIOs must personally affirm their responsibility for maintaining an adequate internal control structure and procedures for financial reporting and (per Title III) can be individually liable for shortcomings in the accuracy and completeness of corporate financial reports.

Less well known is just how corporate management and the auditing community design and evaluate internal controls. They rely on the Committee of Sponsoring Organizations of the Treadway Commission (COSO), an organization that provides thought leadership and guidance on internal control, enterprise risk management, and fraud deterrence. COSO promulgated the foundational guidelines in its Framework as far back as 1992 and updated its guidelines in May 2013. Generally speaking, the updated guidelines accommodate a business landscape that has changed considerably over the past two decades. Of interest to those who are naturally drawn to this blog is that the new Framework draws special attention to technology assets. The updated guidelines set a deadline — today — for companies to adopt their new Framework for internal controls.
The new Framework is composed of five components of internal control: control environment, risk assessment, control activities, information and communication, and monitoring activities. These components embody 17 principles representing the fundamental concepts of internal control. The principle of interest to Finance/Accounting and IT executives is a control activity: “The organization selects and develops general control activities over technology to support the achievement of objectives.”

What does this mean for corporate staff? The new Framework has implications for IT asset management (ITAM), IT service management (ITSM), and data security — a set of disciplines we call technology asset management.
Internal auditors will be obliged to scrutinize their IT and procurement departments much more carefully than ever before. The quality and degree of housekeeping around ITAM will have to escalate dramatically. Organizations will need to know persistently whether software entitlements match actual usage (no small feat). Organizations also will have to know where devices are located so they’re not just asset tagged and forgotten. At a time when it is more likely that companies will record furniture rather than software on their balance sheet, the accounting profession is finally addressing the assets that generate significantly more return — and risk — to shareholders.

A company that has outsourced IT to a third party should be especially interested in the updated COSO Framework. Outsource service providers can give companies the false comfort that the ITAM box is checked, but they often fall short of comprehensive control.

Considering how vulnerable companies have been to security threats and how increasingly public security failures have become, we predict that these new SOX guidelines will be an important catalyst for improvement.

Technology asset management is hard to get right. It is a practice that cannot be executed simply by purchasing software. Instead, a rigorous SOX and governance plan should be created with one’s organization’s needs in mind.

10-signs-youreinatoxicworkplaceandhowtostayfocused

10 Signs You’re In A Toxic Workplace and How to Stay Cool?

A Toxin is a person or group who live within the walls of your organization. They suck the energy and creativity away from your co-workers and sometimes even clients. These individuals can be described as a bull in a china shop, which is not a good thing.
A Toxin loves to be in authority or leadership positions, as it allows him or her to feel as if they are in control even if it is just a department or team of two. They are harder to spot in larger organizations and can exist for years without anyone ever noticing.
In organizations that are smaller, flat structured, and more entrepreneurial minded, they will often stick out like a sore thumb. You can often tell who your Toxin is because no one wants to collaborate with them. They avoid them like a toxic plague.


Here are some ways to spot an organizational Toxin:

  1. Confrontational and very hard to approach. Having meetings with a Toxin leaves you feeling drained and frustrated.
  2. Not receptive to new ideas unless it’s their own. A Toxin will sometimes take your ideas and relabel them as their own.
  3. Not a team player. A Toxin will begin most sentences with the letter “I” verses “we.” A toxin also tends to always put down the team or organization instead of lifting them up
  4. Has a large ego. Behind closed doors a Toxin will refer to themselves as the go-to person of the organization or department. No one knows as much as they do or are as skilled, according to the Toxin. Example: I made this, I did this, I designed this.
  5. Can be intimidating to others. A Toxin can be arrogant and uses it as a way to intimidate their fellow coworkers. However, it is important to note that there is a big difference between being confident and being arrogant. Confident people tend to inspire others; arrogant people tend to use their presence as a way to control others.
  6. Often has a lack of prerequisite skills. Toxins tend to lack the required skills for their position and will blame others as a way of diverting attention away from their low skill sets.
  7. Disrespectful. Toxins speak in a patronizing and condescending voice to the people around them.
  8. Judgmental. Being judgmental is not normal and is part of a Toxin’s behavior. They tend to jump to conclusions without fully understanding the problem and will blame others when their plan falls apart.
  9. Victim. A Toxin always plays the victim role. It’s their way of shielding criticism. Don’t fall for it. If you feel it’s interfering with your work or assignments it’s time to speak up.
  10. Insecure. Toxins will continue to seek acceptance and approve from their peers. It’s hard to spot at first, but after awhile you will find yourself constantly lifting their ego and yourself drained and confused.

If any of these attributes sound familiar, you have a toxin within your organization and you need to speak up. Tell your manager. Like toxins in the air and water, they don’t just go away without proper action. They mutate and spread. You need to take charge either by yourself or as a team and let the leaders of your organization know this Toxin is killing your organization and your energy. Document. Document. Document. It’s hard to go to HR or upper management without proof. Start documenting early and keep your notes organized and somewhere you can retrieve them quickly to send.
If the Toxin is your manager, tell your managers’ manager. Don’t wait until you’re on the verge of quitting or filling out your exit interview survey to say something.

10 Product Owner Responsibilities: Expectations vs. Reality

10 Product Owner Responsibilities: Expectations vs. Reality

Product owners are at the center of every development cycle. But what do they do?

To find this answer you could go look through Scrums definition, but truth is each organization approaches the title differently. This can also change depending on budgets and resource availability. In other words, don’t get too caught up on titles.

Product owner’s typically have several key roles and responsibilities covering everything from business strategy to product design. Let’s first understand what exactly is a “Product Owner”

What is a product owner?
At the most basic level, a product owner is the leader responsible for maximizing the value of the products created by a scrum development team.

Overview of Product Owner Roles and Responsibilities
The product owner takes the lead in many areas of product development. One day they will need to access their deep well of market knowledge to strategize and present their vision to stakeholders. Another day they will need to roll up their developer sleeves to help the team meet their goals during a sprint.

Here are just a few of a product owner’s responsibilities:

  1. Defining the vision
    The agile product owner is the point person on the product development team, using their high-level perspective to define goals and create a vision for development projects. Notice I mention “high-level”. Product Owners do not need to go deep into the weeds or try to play developer and administrator. They do need have a documented clear vision.

Product owners are responsible for communicating with stakeholders across the board, including customers, business managers, and the development team to make sure the goals are clear, and the vision is aligned with business objectives. I have worked on projects were development is in a vacuum and the vision changes more times one can count which causes confusion and an always unfinished product.

Having a product owner with a higher perspective ensures that the team maintains a cohesive vision despite the flexible and often fast-paced nature of agile product development. Everyone needs to be on the same page for a project to work effectively.

A product owner can help the team maintain that vision is by creating a product road-map. The product road-map is a high-level, strategic visual summary that outlines the vision and direction for the product offering over time. It is both a strategic guide for stakeholders to reference as well as a plan for execution. This road-map is a living breathing document that must be updated frequently by the product owner.

  1. Managing the product backlog
    One of the most important responsibilities for a product owner is managing the product backlog. This is the development team’s project to-do list.

The product owner’s responsibility is to create the list of backlog items and prioritize them based on the overall strategy and business objectives. Additionally, the product owner will need to map out project dependencies to inform the necessary sequence of development.

Like the roadmap, the product backlog isn’t a static to-do list. It is a live document that should be continually updated based on evolving project needs throughout development.

Because the product backlog will change frequently, the product owner must make the list accessible and available to all executive, business and technical stakeholders to ensure optimized performance and project outcomes.

  1. Prioritizing needs
    Another key role of the product owner is to prioritize needs. Like a project manager they must juggle the triangle of scope, budget, and time, weighing priorities according to the needs and objectives of stakeholders.

For example, if the product under development needs to launch within six months, that constrains the scope of the project. As the project evolves, the product owner will have to gauge which areas have flexibility and which don’t to determine how and when each iteration and product element will be developed.

  1. Overseeing development stages
    With the vision, strategy, and product priorities set, the product owner should spend a significant amount of time overseeing the actual development of the product. They are a key player throughout each event, including planning, refinement, review, and sprint. The product owner also needs to understand their limitations and allow teams to work independently without constant distractions.

During the planning stages, the agile product owner works with stakeholders to identify and organize the steps required for the next iteration. They will then meet with their team to refine the process, identify areas for improvement, and support the sprint.

  1. Anticipating client needs
    The successful product owner will be an expert at understanding and anticipating the client’s needs to more effectively manage the development process.

Their deep market knowledge and communication skills allow them to anticipate problems or needs and address them.

  1. Acting as primary liaison
    The product owner is also the primary communicator and link between stakeholders and teams. As such, they must be expert communicators, ability to negate on behalf of the stakeholders needs, making sure there’s buy-in from stakeholders on all major decisions and strategy and clear instructions and deliverables for the developers. If you’re not approachable and cannot take criticism well your product is doomed.
  2. Evaluating product progress at each iteration
    The product owner is accountable for each stage of the development process and the final product. They take a primary role in inspecting and evaluating product progress through each iteration. The product owner makes the judgment call on the performance, deciding if the team needs to go back to the drawing board or if they can move on to the next steps.
  3. Understanding Business Needs
    Product Owners needs to know to use Lean verses a full-blown product. If your product and project is over budget, you may want to reevaluate your priorities and focus more on what’s possible now verses the future.
  4. Know Who is Who
    It’s hard to lead a successful product if you don’t know what your title is. At the same time if no one has been given the title of product owner, no one has the steering wheel.
  5. Present Often & Know Your Audience
    A good product owner is always presenting value added features. Before any presentation the question needs to be asked “What value will this add to x?” How do you know it will add value? Never present technical solutions to business stakeholders. As an example: Apple iPhone is just a smart phone, it’s a tool that allows you to have a better life once you use it.
carlbjohnson.com-better speech

Five Rules to Giving A Better Speech

I was reminded the other day how important it is to read a room and adjust your speech to your audience. No one wants to hear you talk about yourself for an hour. People want to hear things that are directly connected to them. Before you speak to a diverse audience take a minute to understand their “WIIFM” what’s in it for me. Leaders of companies someone’s lives in a bubble of numbers, decisions, and risk versus reward. That’s what their entire day looks like. From the moment they get into the office they have one of the above on their mind. As much as they would like to downplay it when they are in a room of employees, they don’t people. They see wages, healthcare, 401k cost, FTE’s, tax filings, etc. Sometimes it’s hard to switch to seeing people as people.

Here are five rules to giving a better speech:

Good Leaders Don’t Talk About Themselves or Their Company
When you’re giving your speech think of how many times you are using the word “I”. If over 70% of your speech is using the word “I” or the phrase “for me” refocus and think about your audience.

Have Someone Else Write Your Speech
Often, we are in a rush and cobble some words together on a paper and call it a speech. A speech should have seven elements to it.

Who are you? Briefly let your audience know why they should be listening to you – “I’m the VP of operations at Spacely Space Sprockets. I handle your accounts”

Why are you talking to them? – “I wanted to talk with you today because….”

What are you going to talk about? “Over the next hour I will discuss some of the changes in operations…”

What’s in it for them? – “Without your assistance we would not have won….”

What in it for them, again? – “Going forward everyone at Spacely Space Sprockets will receive…”

Thank them for listening – “Again, I know you have many things you could be doing….”

Let them know you’ll follow-up – “I’ll have Jane from HR follow-up with you on….”

Practice Your Written Speech on Your Friends or Spouse
Notice I didn’t say your employees. Your employees no matter how long they have known you will only tell you what you want to hear. Even if they do tell you the truth they will not tell you the whole truth. Your friends or spouse are not afraid of losing their jobs. You may not like what they have to say, but it will be said out of honesty.

Keep Your Audience Guessing
Steve Jobs wasn’t the best speaker in the world, but he kept you guessing in his announcements of new Apple products. He kept his audience on the edge of their seats. Not because of new Apple products coming out in the fall. Instead, he would keep his audience guessing because he knew spent the last year thinking about what his customers wanted. Not what he wanted. When you speak what your audience wants you will always have their attention and you will always keep them guessing.

Don’t Make Your Speech into a Ted Talk
I love Ted Talks. They are motivating, captivating and I always walk away learning something new. Unless you’re rolling out a new cure for cancer, leave the cleverness at home. Ted Talk presenters rehearse, have the support of large production staff and have been waiting for the moment to be on that stage all their lives. You are told you need to speak to your employees two days ago. Keep your speech uplifting and work in your sense of humor and personality as much as possible. More importantly, keep your speech short and to the point.

It’s okay to veer off course if you keep the above in mind. One wants to see you read a script for an hour. They came to see you speak not to see you read.

What has been your experience as an audience member or a speaker. Let me know in the comments section.

I was reminded the other day how important it is to read a room and adjust your speech to your audience. No one wants to hear you talk about yourself for an hour. People want to hear things that are directly connected to them. Before you speak to a diverse audience take a minute to understand their “WIIFM” what’s in it for me. Leaders of companies someone’s lives in a bubble of numbers, decisions and risk verses reward. That’s what their entire day looks like. From the moment they get into the office they have one of the above on their mind. As much as they would like to downplay it, when they are in a room of employees, they don’t people. They see wages, healthcare, 401k cost, FTE’s, tax filings, etc. Sometimes its hard to switch to seeing people as people.

Here are five rules to giving a better speech:

Good Leaders Don’t Talk About Themselves or Their Company
When you’re giving your speech think of how many times you are using the word “I”. If over 70% of your speech is using the word “I” or the phrase “for me” refocus and think about your audience.

Have Someone Else Write Your Speech
Often, we are in a rush and cobble some words together on a paper and call it a speech. A speech should have seven elements to it.

Who are you? Briefly let your audience know why they should be listening to you – “I’m the VP of operations at Spacely Space Sprockets. I handle your accounts”

Why are you talking to them? – “I wanted to talk with you today because….”

What are you going to talk about? “Over the next hour I will discuss some of the changes in operations…”

What’s in it for them? – “Without your assistance we would not have won….”

What in it for them, again? – “Going forward everyone at Spacely Space Sprockets will receive…”

Thank them for listening – “Again, I know you have many things you could be doing….”

Let them know you’ll follow-up – “I’ll have Jane from HR follow-up with you on….”

Practice Your Written Speech on Your Friends or Spouse
Notice I didn’t say your employees. Your employees no matter how long they have known you will only tell you what you want to hear. Even if they do tell you truth they will not tell you the whole truth. Your friends or spouse are not afraid of losing their jobs. You may not like what they have to say, but it will be said out of honesty.

Keep Your Audience Guessing
Steve Jobs wasn’t the best speaker in the world, but he kept you guessing in his announcements of new Apple products. He kept his audience on the edge of their seat. Not because of new Apple products coming out in the fall. Instead, he would keep his audience guessing because he knew spent the last year thinking about what his customers wanted. Not what he wanted. When you speak what your audience wants you will always have their attention and you will always keep them guessing.

Don’t Make Your Speech into a Ted Talk
I love Ted Talks. They are motivating, captivating and I always walk away learning something new. Unless your rolling out a new cure for cancer, leave the cleverness at home. Ted Talk presenters rehearse, have the support of a large production staff and have been waiting for the moment to be on that stage all their life. You are told you need to speak to your employees two days ago. Keep your speech uplifting and work in your sense of humor and personality as much as possible. More importantly, keep your speech short and to the point.

It’s okay to veer off course if you keep the above in mind. One wants to see you read a script for an hour. They came to see you speak not to see you read.

What has been your experience as an audience member or a speaker. Let me know in the comments section.

Are You Really Running an Agile Team & Project?

Are You Really Running an Agile Team & Project?

In 2001, at Utah’s Snowbird ski resort, 17 software developers got together and produced the groundbreaking Agile Manifesto.

It was meant to streamline the software development process by de-emphasizing inefficient practices such as heavy documentation, excessive meetings, and rigid adherence to process.

There’s no way they could have known back then what the Agile movement would become. More than 15 years later, Agile is everywhere.

It has become a full-on business buzzword among the ranks of “synergy,” “disruptive,” and the all-time great, “thinking outside the box.”

Everyone from the sales department to the mail-room is talking about who’s more Agile than whom.

The big difference between Agile and the rest of the project management buzzwords that came before it? Agile is an actual approach to project management with an actual definition.

This article will cut through the clutter to give a clear, concise definition of the term so that you can correct your manager the next time they talk about how Agile they were with their series of afternoon meetings to plan next month’s series of planning meetings.

By understanding what Agile really means, you’ll also be better equipped to help implement Agile practices at your organization, and recognize situations that could be improved with a dash of Agile (like nixing the weekly meeting-planning meeting).

We’ll also look at three real world examples of Agile project management in action.

A definition of Agile project management
What is agile project management? The first—and perhaps most pure—definition of Agile project management comes from the Agile Manifesto itself:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
  • But we can distill that somewhat arcane summary to come up with a more concise definition:

Now let’s break that down.

Agile is iterative, meaning that it is done in pieces (sprints), with each sprint building and improving off the lessons learned from the previous sprint. This is where the Scrum framework comes into the equation. As Gartner research director Nathan Wilson said at the 2017 Gartner PPM Summit, “Scrum is a way of organizing work to promote agility.”
Agile is an approach and mindset. It’s not a textbook, or a list of instructions, or a certification. In fact, trying to turn Agile methodology into a black and white template goes against everything that Agile is. It would be like trying to give someone a detailed, step-by-step plan on how to be “cool,” or play jazz. However, there is project management software that is designed specifically to promote agility.
Agile project management is all about efficient communication over documentation, or convoluted email chains, or excessive meetings. According to the 12 principles behind the Agile Manifesto: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” If you can communicate something with a ten-second conversation instead of an email, you should. This is where the daily scrum comes into play.
Agile is all about producing tangible, working results after each iteration. This is an important one. According to the 12 principles, “Working software is the primary measure of progress.” To compare Agile to the editorial process—you deliver a rough draft, then revise based on your editor’s suggestions. You’re not delivering the entire piece all at once on the day it goes to press.

Why Agile matters
So that’s what Agile is, but why is it important?

According to the Project Management Institute, more than 70% of organizations have incorporated some Agile approaches, while more than a quarter of manufacturing firms use Agile exclusively.

If your business is not using Agile, you’re in the increasing minority, and you’re falling behind as a result.