the argument for #NoProjectsThis article is an inoculation against the #NoProjects meme.
Projects are great. Despite the cry on the web about projects being bad for business they can really help you do a better job of organizing your work.
I am writing this as a counter to a meme about why projects are evil and need to be abolished. What was once a sentiment is now a movement (with it's own hashtag, soÂ it really is legit.)
The main arguments against projects seem to be;
- Projects are temporary organisations. People that work on projects don't have to live with the consequences of the work they do, and so will eagerly take quality shortcuts that someone else is going to have to pay for
- Projects are organised around impossible goals. Some executive somewhere wants a new product out to market, or internal process fixed and all the big decisions about time money and scope are done before you arrive.Â
So, drumroll please.
Read more Â»
There's another rash of Twitter posters supporting the conjecture that decisions can be made about how to spend other people's money without estimating the impact and outcome of that decision. This is a core premise of #NoEstimates from the Original Poster
Here's a starting point to learn that simply not trueÂ
- Theory of Decision under Uncertainty,Â Itzhak Gilboa,Â July 2008
- Decision Analysis for the Professional
- Managerial Decision Making Under Risk and Uncertainty Ari Riabacke
There are 100's more books, papers, conference proceedings on the topic ofÂ decisionÂ making in the presence of uncertanty.
It comes down to a simple concept
All project work is uncertain. Reducible uncertainties (epistemic) and irreducible uncertainties (aleatory). When money is being provided to development software, those providing the money a reasonable expectation to know something about when you will be providing the value in exchange for that money, how much money will be required to provide that value, and what capabilities will be provided in exchange for that money. The field of study where these questions and answers live isÂ microeconomics of decision making. Software development decision making is a well studied subset of that field.
When it is conjecture decisions can be made in the presence of uncertanty without estimates - like the Original Poster did, and there is no supporting theory, principle, practices, or evidence of how that can be done -Â run away - it's a bogus claim.ÂRelated articles Making Decisions In The Presence of Uncertainty Essential Reading List for Managing Other People's Money Herding Cats: Decision Making in the Presence of Uncertainty Herding Cats: Thoughts on Suggestions That Violate Principles of Finance, Probability, and Statistics Making Conjectures Without Testable Outcomes
I'veÂ started reading Vasco's book #NoEstimates and will write a detailedÂ deconstruction. I got the Kindle version, so I have a $10 investment at risk. Let's start with some graphs that have been around and their misinformation that forms the basis of the book.
The Chaos Report graph,is theÂ 1st one. This graph is from old 2004 numbers. That's 12 year old numbers. Many times the books uses 12, 16, even 25 year old reports as the basis of the suggestion that Not Estimating fixes the problems in the reports. The Chaos reports have been thoroughly debunked asÂ self selected samples usingÂ uncalibratedÂ surveys for the units of measure forÂ projectÂ failure.Â Here's a few comments on the Standish reporting process. But first remember, Standish does not say what the units of measure are for Success, Challenged, or Failure. Without the units of measure, the actual statistics of the projects and the statistical ranges of those projects for each of the threeÂ categories, the units as essentially bogus. Good fodder for selling consulting services or for use by those with an idea to sell, but worthless for decision making about the root cause of Failure, Challenged, or even Success. Any undergraduateÂ design ofÂ experiments class would have all that information in the public.Â
So the 1st thing to read when you encounter data like this is Project Success:Â A Multidimensional StrategicÂ Concept,Â Aaron J. Shenhar, Dov Dvir, Ofer Levy and Alan C. Maltz. Only then start to assess the numbers. Most likely, like the numbers in the book, they're not credible to support the hypothesis. Which by the way there is no hypothesis forÂ you can makeÂ decisionsÂ in the presence of uncertanty without estimating
So let's look further at the difficulties with Standish and why NOT to use it as the basis of a conjecture
- Standish Report
- Standish Report and Naive Statistics
- Finally a Challenge to the Standish Report
- Standish Report and Naive Statistics
- Project Failure Rate
- "The Standish Report: Does it Really Describe a Software Crisis?" Robert Glass,Communications of the ACM, August 2006
- "How Large are Software Overruns? Critical Comments on the Standish Group's Chaos Report," SIMULA Research Laboratory, 2006-03-21
- "Software Cost Overruns: How Large are They and How Should They be Measured?" SIMULA Research Laboratory, 2005-08-30
- The nonexistent Software CrisisÂ - BTW Vasco quotes a NATO report about theÂ software crisis for 40 year old process using FORTRAN 77 code developed using batch processing systems. I worked programs like that just out of grad school for missile defense systems. It was a crisis, but that was fixed when IDE's, workstations, and other modern tools came along.
- Go read Scott's assessment to see actual data with actual statistics and stop listening the bad data, poor research, and unsubstantiated conjectures.
- How Successful Are IT Projects, Really?Â
- 2010 IT Project Success RatesÂ
- Software Development Success RatesÂ
- Defining SuccessÂ
A simple google search would have found all this research and many many more. I get the sense V didn't do his homework. The bibliography has very few references to actually estimating, no actual estimating books, papers, or research sites. Just personal anecdotes from a Â set of experiences as a developer.
The Standish Report failure mode is described inÂ Darrell Huff'sÂ How to Lie With Statistics -Â self select the samples from the survey. Standish does not provide any population statistics for their survey.
- How many surveys were set out?
- How many responded?
- Of those responding, how many were statistically significant?
- What does it means in terms of actual measures of performance to theÂ troubled?
- If the project was over budget, was the needed budget estimate correct?
- If the project was late, was the original schedule credible?
None of these questions are answered in Standish reports. No Estimate picks these serious statistical sampling error up and uses the, as the basis of the pure-conjecture that Not Estimating is going to fix the problems. This would garner a high school D is the Stats class.
Next comes a chart that makesÂ a similar error. This reference is from Steve McConnell's book, but isÂ actually from another source. The No Estimates book does a poor job of keeping the references straight. It is common toÂ misattribute a report, a graph, even a phrase. The book needs a professional editor.
The graph below is used to show that estimates are usually wrong. But there is a critical misunderstanding about the data.
- It starts with a straight line calledÂ perfect accuracy/. First there are two attributes of any estimate.Â AccuracyÂ andÂ precision. There is no such thing as perfect accuracy in the estimating business. An estimate is an approximation of reality.
- The sample projects show they did not meet theÂ perfect accuracy - whatever that might have been. This knowledge can only be obtainedÂ after the work has been done. Either at the end or during the project - cumulative to date.Â
- But there are two sources of the variances ofÂ estimates and actuals
- The estimate was in error.
- Work was not performed as needed to meet the estimated completion date.
- The original author of this graph, does not say which is the case, or if both are the case.
- The Root Cause analysis of the variances between Estimate and Actual is not available.
- The graph shows a symptom but not the Cause. This is a simple and simple minded mistake, when knowledge and experience in Root Cause analysis is missing. Here's a start for fixing that gap.
I'm in the early parts of the book and already have a half dozen pages of notes for either fallacies, incorrect principles, 30 year old references, and other serious mistakes onÂ understanding on how decisions are made in the presence of uncertainty. My short assessment isÂ
It's a concept built on sand.Related articles Myth's Abound All Project Numbers are Random Numbers - Act Accordingly The Failure of Open Loop Thinking How to "Lie" with Statistics Statistical Significance How to Estimate Software Development Capabilities Based Planning IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes
Many organizations make the same mistakes when it comes to scaling Agile and DevOps and then attempt to rectify those mistakes by formulating a new strategyâonly to miss the real reasons why the initiative failed.
As someone who helps companies through software delivery transformations, Iâve seen my share of ineffective behaviors. What I find most difficult to watch is organizations that make the same agile and DevOps scaling mistakes year after year.
Recently I made a visit to a Fortune 100 company where the last two VPs responsible for the transformation had been let go. In the meeting, I took some notes about what might be happening to the companyâs Agile and DevOps initiatives to get them into such a bad state. I had a vivid image of a billion dollars wasted, and billions more that would be wasted if they didnât learn from the past. This lead me to create a set of anti-patterns that you want to avoid at all costs.
You can read more about the anti-patterns – the mistakes made by large organizations during Agile DevOps transformations – in my article published in CMCrossroads: How to Guarantee Failure in Your Agile DevOps Transformation.
And if you have questions or would like to discuss my findings and recommendations, leave a comment and I would be happy to discuss.
Project boards limit your visibility into your team's capacity and performance. Learn how team Kanban boards enable continuous improvement.
The post Are Project Boards Really Kanban? How Old-School Project Management Prevents Continuous Improvement appeared first on Blog | LeanKit.
As we celebrate Pride this year, weâd like to take a moment to reflect upon the recent tragedy in Orlando. Our hearts go out to the victims and their families, friends, allies, and communities.
Now more than ever, we each have an opportunity to be an ally. In doing so, we can encourage compassion, kindness, and loveânot just in the LGBTQIA community, but in every community to which we belong.
Employers should be allies. By providing a hiring and working experience in which all peopleÂ feel they are equally respected and valued, regardless of gender identity or expression, sexual orientation, religion, ethnicity, age, ability, citizenship, or any other aspect which makes someone unique, companies can contribute positively to this equation.Employers should be allies. #organizedwithprideTweet
AsanaÂ strives to be the change we want to see in the workplace, and that is one which is radically inclusive. As we prepare to celebrate Pride this weekend, weâd like to highlight the members of the LGBTQIA community who are part of Team Asana, and take a look at how we can all create a more diverse, inclusive, and inspiring company.
We sat down with Ashley, Elden, Emilie, Josh, Patrick, Rachel, andÂ Tim toÂ talk about education, support, and empowerment at the Asana office.Creating a more LGBTQIA-inclusive environment Educate
âBeing inclusive is about education and openness to learning about the constant evolution of identity,â Josh explains. âBy being curious and open, you can show any diverse group or minority that you support and would like to learn more about them.”
âEven though Iâm part of the LGBTQIA community, I can always be educating myself about the experiences of others in the community,â says Emilie from the marketing team. âFor example, I know and understand so much more about the transgender, genderqueer, and gender-nonconforming experience than I ever did before some of our dynamic and enlightening all-hands sessions on these areas here at Asana, led by community experts such as Mordecai Cohen Ettinger of CIIS.âSupport LGBTQIA Employees
There are lots of ways to support all employees, fromÂ company infrastructureÂ to day-to-day interactions. InclusiveÂ benefitsÂ andÂ facilities,Â such asÂ gender-inclusive bathrooms andÂ insurance that covers mental health careÂ and all parents,Â endeavor to provide support from whichÂ all employees can benefit. We also encourage people to become aware of preferred pronouns, and recognize unconscious biases and assumptions that might arise around language. Elden (they/them/theirs), a member of our engineering team, notes that âwhen companies encourage introducing pronouns, itâs great. I’ve had a lot of people here [at Asana] ask me if I wanted them to introduce my pronouns, which I find really helpful and welcoming.âEmpower
Empowering employees is an essential part to creating an inclusive environment. Asana has âaÂ unique organizational structure that empowers all people to contribute and be heard across projects and teams, essentially allowing individuals who have different gender identities or backgrounds to speak up in places they might not have always felt so comfortable to do so,â says Ashley, our web analytics lead. Rachel, an engineer, addsÂ that “noticing when people are passionate about something and giving them the space to champion their passions, such as diversity in recruiting, further empowers them.”
In addition toÂ empowering employees, building a supportive environment and culture of learning from mistakes is important to allow for growth, says Tim from the recruiting team. At Asana, âweâre often of the opinion that itâs even better for someone to take on more challenges after theyâve made mistakes, because they’ve learned from them.âBe open and communicate
Openness and communication with all groups lead to an increasingly transparent and inclusive environment. We focus on fostering openness in our work environment, personal lives, and within our product. At work, âour leadership trainingÂ gives people the space to be vulnerable with their emotions, building in a support system because we all go through the training,â says Josh. According to Ashley, we âput a lot of effort into getting to know each other beyond just work interactions through team off-sites and meals together. They give us spaces to get to know co-workers as humans, which creates a really friendly, supportive atmosphere.â Tim feels that âthe heart feature in Asana helps people show support and be encouraging. In email, unless someone actively responds with support, it doesnât get communicated.âEngage with your community
Companies can show their support by partnering with organizations or events that support marginalized groups. Asana has sponsored and spoken at the Out For Undergrad Technology conference for three years, and recently sponsored and spoke at Lesbians Who Tech.Bring your authentic self to work
We encourage all Asanas to bring their authentic selves to work. Patrick, from sales, notes that, âIt’s weird, I donât feel like I have to try to bring my full self to work, which I used to think about more before working in techânow I don’t have to psych myself up just to be myself each day [laughs].â To help people feel like they can be themselves, we âaffirm that we really do mean the sincere-sounding things that we sayâlike, can you really have managers who are responsible for emotional and career growth? Yes, you can,â says Rachel. Finally, even something as simple as aÂ flexible dress code can matter. Josh notes, âI appreciate that so many other people use clothing as an avenue to express themselves and it’s something that I’ve been able to do here. I can have fun with clothing and my personal expression of how I want to be seen at work and not have it fit into rigid fashion format or corporate dress code.âEncourage employees to bring their authentic selves to work. #organizedwithprideTweet
All of this said, Patrick reminds us that âthereâs a flipside to having been in an inclusive environment for so long, which is making sure you respect people’s journey to bringing their full selves to work. If they don’t want to or aren’t ready, they shouldn’t be pushed in that direction.âThe LGBTQIA community and tech On change
There have been many changes in the LGBTQIA community in the past few years. To Patrick, âThe tech community has been at the forefront of changes that weâre now seeing across wider corporate America around how employees in the community are treated in the workplace,â and weâre starting to finally seeÂ changes outside of tech.On support
We have also seen a lot of support programs showing up in tech, like mentorship and Employee Resource Groups (ERGs). Tim has noticed âa shift from focusing on ourselves at work to thinking about those who are coming into tech or need more support.â There also are more and more spaces for people to meet in, whether theyâre happy hours ,Â conferences, or meetups.On success
For Josh, seeing examples of success âlike Tim Cook becoming CEO of Apple and other examples of people being their full selvesâ has been inspiring.The workâs not done.
There are many ways to get involved in LGBTQIA allyshipÂ in both the workplace and your community, including speaking at events, talking to candidates about diversity, asking about gender pronounsÂ – or even just providing open channels for communication and flagging issues. Rachel feels âmost seen by [her] company when others notice the issues that [sheâd] otherwise have to be the one speaking up about.â There’s always room for improvement, too — and the work is far from done. But when “a company can acknowledge its shortcomings and do work without it only being driven by theÂ marginalized employeeÂ groupâthatâs cool.â
Every week we bring you the best of what weâre reading from around the web. This weekâs stories center on speed, efficiency, working well with others and thereâs an intriguing piece on how a Harvard Business School professor studied Pixarâs formula to rethink leadership and innovation. I hope these posts bring you a bit of joy and insight into getting the most out of your day. Happy reading!
This Professor Teaches Pixarâs Approach to Creative Genius â Quartz.com
How to Double Your Writing Speed â Â Huffington PostÂ
Itâs Time to Stop Trying to Do It All â Fortune.com
4 Soft Skills You Need to Work on, and Why â Forbes.com
7 Time-Saving Ways to Automate Your Everyday Tasks â Fast Company
Bonus Story! Our most read blog post of the week:
Like what you read? Have suggestions? Drop me a note @mmerwin.
For skillful insight onÂ how to be the top dog of project managers, download our handbook, “The Ultimate ProjectÂ Management Guide.”
The post What Weâre Reading This Week: A Peak Into Creative Genius, Productivity and More appeared first on LiquidPlanner.
In this video I interview author Penny Pullan about her new book, Virtual Leadership: Practical Strategies for Getting the Best Out of Virtual Work and Virtual Teams, which is out this year. We filmed this video in an apartment in Barcelona where we were staying during the PMI Global Congress. It was Penny’s idea to have wine in the film (although I didn’t argue). I have edited out most of the giggling!
Penny has kindly organised you a discount.
Go to the publisher’s website and use the coupon FRIENDSOFPENNY for 20% off.
This article contains affiliate links.
You'll also like:
- Penny Pullan talks about writing A Short Guide to Facilitating Risk Management In this video I talk to Penny Pullan, co-author of A Short Guide to Facilitating Risk Management. If you prefer to read a transcript, that...
- Leading Effective Virtual Teams [Book Review] Leading Effective Virtual Teams is one of the harder books I have had to review, but one of the easiest to read. It's very practical,...
- Project Management Answers: Interview with author Jeff Furman The PMBOKÂź Guide v5 refresh introduced new topics for students taking the PMP exam. Jeff Furman, author of The Project Management Answer Book, has just...
- 5 Tips for Virtual Meetings [Video] Watch this video to find out the 5 things you can do to make your virtual team meetings more interesting and more productive for everyone....
- 4 Easy Tips For Effective Virtual Meetings Virtual meetings are a fact of life. These 4 easy tips take only moments to put into practice but will hugely improve the quality of...
Software Engineering Intern
Project:Â Web-based Management System for Construction Equipment
âI chose SEP because of the opportunities as well as the culture. SEP cares about its employees and wants them to grow and learn and feel comfortable. There are also a variety of projects, which means lots of different technologies and programming languages thatÂ teams can work with.â
Software Engineering Intern
Major: Computer Engineering
Project: Product Pricing Analysis Software Application
âI picked SEP because one summer here could teach me so much. At SEP, I knew Iâd be surrounded by really smart engineers and I was looking forward to picking their brains and learning about the software development process. Most importantly, I knew my work would be relevant and exciting. Oh, and the office is really, really cool.â
Software Engineering Intern
Major: Computer Science
Project: FORUM Mobile Banking App
âI chose to return to SEP for my 5th internship with the company because they have a great atmosphere where people are open to helping others, questions are encouraged, and learning is a priority. I find that every year Iâm at SEP, they offer new experiences and learning opportunities due to the variety of projects and team members.Â I enjoy and grow from every internshipÂ that I spend here.â
Major: Industrial Engineering
Project: User Research Methods & Recruitment Marketing
âI chose SEP because I knew an internship hereÂ would mean the opportunity to do meaningful work on real projects. Everyone at SEP is so eager to learn, curious, and passionate about the work they do. These thingsÂ really drew me to SEP as a company, along with the incredible culture they have.â
Software Engineering Intern
Major: Computer Science
Project:Â Virtual Collaboration Software
âI knew that I wanted to work for SEP when I went to one of their info sessions at Rose-Hulman. Â I liked everything I saw during their presentation, and I visited them at the career fair and liked what I saw even more. I’m so glad I attended their session, because I ended up working at this awesome company!â
Software Engineering Intern
Major: Computer Science/Math
Project: Software for a Medical Device Manufacturer
âI chose SEP for my internship because it offered so many additional opportunities outside of work. The startup weekend was one thing that drew me in. The fact that SEP was dedicated and committed to letting their employees be creative was a big factor in my decision. I liked that SEPLabs supported new ideas and innovation internally.â
Software Engineering Intern
Major: Computer Science
Project:Â Embedded Display System for Agricultural Machinery
âFrom the research I did on SEP before I interviewed, everyone at SEP seemed to really like the variety of the projects they worked on. Some said it was almost like having a different job every 5 years. This freshness was definitely appealing to me.â
Software Engineering Intern
Major: Computer Science
Project: Embedded Display System for Agricultural Machinery
âI chose SEP because I saw them at the career fair and heard they were from Carmel, which is where Iâm from. I read about them online, asked both the employees and other students about the company, and became more interested in interning with them over time. SEP was also at a few hackathons I attended, and I metÂ employees who helped me get a better understanding of SEP’s culture. A few interviews and a couple emails later and now Iâm here!â
This week marked the official start of summer in the northern hemisphere, and here at Tasktop, weâve declared this the Summer of Agile. We got started a bit early with last weekâs webinar: SAFe & Requirements Management: Oxymoron or Practical Reality? with our VP of Product Management, Nicole Bryan. To be fair, Nicole and I are based in Austin, Texas where summer has been in full swing for a while. Next month, weâll be joined by Dave West from Scrum.org for the second part of our series: Beyond the Scrum Team: Delivering âDoneâ at Scale.
But, the Summer of Agile isnât all about webinars. For one, weâre putting together a summer reading list to help everyone brush up on their Agile skills. Weâd love to hear what you think should be included, and have gathered a few recommendations from the Tasktop team to get things started. Weâre looking for a variety of titles ranging from introductions to the methodology to deeper discussions for more experienced practitioners.
To start us off, we have a couple of titles plucked right off the bookshelf of Tasktop CEO Mik Kersten:
Agile!: The Good, the Hype and the Ugly by Bertrand Meyer
Agile Project Management with Scrum by Ken Schwaber
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble & David Farley
Scrum: The Art of Doing Twice the Work in Half the Time
by Jeff Sutherland & J.J. Sutherland
ThisÂ bookÂ was a great intro to Scrum from one of the framework’s co-creators. As a non-engineer in a tech company, I particularly enjoyed the stories about how Scrum has been applied outside of software development, and found the discussion of the perils of multi-tasking and the importance of the doing the job right the first time to be widely applicable.
Recommended by: Sarah Ryan, Marketing Operations Manager (Yeah, thatâs me.)
Kanban: Successful Evolutionary Change for Your Technology Business
by David J Anderson
Excellent introduction and in-depth look at implementing a kanban system for software delivery. Also very useful for practical implementation of kanban, and being able to grow a kanban system within a system of other constraints.Â The author is an authority on the subject.
Recommended by: Ryan Golbeck, Senior Software Engineer
Agile Testing: A Practical Guide for Testers and Agile Teams
by Lisa Crispin & Janet Gregory
One of the biggest mistakes that organizations make when adopting Agile practices is ignoring how testing fits in. Sadly, itâs all too typical among waterfall teams that testing is relegated to a phase that happens after the coders are done. If âmoving to Agileâ simply means that coders now operate in 2-4 week sprints, then testing gets squeezed even further. This book is a practical introduction of how to avoid this horrible circumstance.
Recommended by: Betty Zakheim, VP of Industry Strategy
As much as we love reading about Agile, sometimes you really want to sit back and watch stick figures explain concepts to you. Thatâs why we decided to open up our reading list to all media.
Agile Project Ownership in a Nutshell by Henrik Kniberg
This is a great intro video. It was introduced to a few of us during our CSM training and has made the rounds internally a few times. The focus is on the PO, but it gives a good overview of the whole framework.
Recommended by: Clint Morgan, Software Engineer
SoâŠwhat about you? Comment to let us know which books, videos, blogs, or other media have helped you learn and improve your Agile practice.
If you specify deliverables in your big picture and small picture roadmaps, you have already done a gross form of ranking. You have already made the big decisions: which feature/parts of features do you want when? You made those decisions based on value to someone.
I see many POs try to use estimation as their only input into rankingÂ stories. How long will something take to complete? If you have a team who can estimate well, that might be helpful. It’s also helpful to see some quick winsÂ if you can. See my most recent series of posts on Estimation for more discussion on ranking by estimation.
Estimation talks about cost. What about value? In agile, we want to work (and deliver) the most valuable work first.
Once you start to think about value, you might even think about value to all your different somebodies. (Jerry Weinberg said, “Quality is value to someone.”) Â Now, you can start considering defects, technical debt, and features.
The PO must rank all three possibilities for a team: features, defects, and technical debt. If you are a PO who has feature-itis, you don’t serve the team, the customer, or the product. Difficult as it is, you have to think about all three to be an effective PO.
The features move the product forward on its roadmap. The defects prevent customers from being happy and prevent movement forward on the roadmap. Technical debt prevents easy releasing and might affect the ease of the team to deliver. Your customers might not see technical debt. They will feel the effects of technical debt in the form of longer release times.
Long ago, I suggested that a specific client considerÂ three backlogs to store the work and then use pair-wise comparison with each item at the top of each queue. (They stored their product backlog, defects, and technical debt in an electronic tool. It was difficult to see all of the possible work.)Â That way, they could see the work they needed to do (and not forget), and they could look at the value of doing each chunk of work. I’m not suggesting keeping three backlogs is a good idea in all cases.Â They needed to see—to make visible—all the possible work. Then, they could assess the value of each chunk of work.
You have many ways to see value. You might look at what causes delays in your organization:
- Technical debt in the form of test automation debt. (Insufficient test automation makes frictionless releasing impossible. Insufficient unit test automation makes experiments and spikes impossible or quite long.)
- Experts who are here, there, and everywhere, providing expertise to all teams. You often have to wait for those experts to arrive to your team.
- Who is waiting for this? Do you have a Very Important Customer waiting for a fix or a feature?
You might see value in features for immediate revenue. I have worked in organizations where, if we released some specific feature, we could gain revenue right away. You might look at waste (one way to consider defects and technical debt).
Especially in programs, I see the need for the PO to say, “I need these three stories from this feature set and two stories from that other feature set.” The more the PO can decompose feature sets into small stories, the more flexibility they have for ranking each story on its own.
Here are questions to ask:
- What is most valuable for our customers, for us to do now?
- What is most valuable for our team, for us to do now?
- What is most valuable for the organization, for us to do now?
- What is most valuable for my learning, as a PO, to decide what to do next?
You might need to rearrange those questions for your context. The more your PO works by value, the more progress the team will make.
The next post will be about when the PO realizes he/she needs to change stories.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
In the past few months, SEP has continued working in partnership with FORUM Credit Union (FCU) to develop the latest update of the FORUM iOS app. In order to create an effective, delightful app, SEPâs FORUM team conducted research within the company to better understand how SEPeers interact with FCU and its app. To begin this research, the team released a survey within SEP.
In the survey, participants were asked aboutâŠ
- general use of the FORUM app and other banking apps
- satisfaction with the FORUM app
- interest in providing feedback to our FORUM iOS team
Additionally, survey participants had the option to choose from a handful of methods to provide in-person feedback to our FORUM team. Depending on their preferences, they could choose to provide feedback by participating in a discussion, sharing their design ideas, or even trying out a prototype of the app.
The first round provided 19 survey responses, and uncovered vital information that will help our FORUM team build the right thing. According to the results, 50% of the survey participants use the FORUM iPhone app. Additionally, the results revealed that the most frequently used feature of the iOS app is the account summary feature, closely followed by the transaction list. More general feedback discovered from our first round of the survey is in the infographic below:
With the first round of responses, our FORUM team was able to perform semi-formal user testing with a handful of SEPeers. For this research study, the team sat down with participants and asked them a few questions as they navigated the prototype of the app. Our FORUM team learned that many users had trouble understanding the icons depicting a check or a memo, and was able to adjust our design accordingly. With the research the team conducted, they were able to gain a better understanding of the FORUM app from the standpoint of the user and design an update better suited for the userâs needs.
Looking forward, the team has released another round of surveys within SEP, and is anticipating more feedback from SEPeers, along with more user research. We are so excited to be working together with FORUM to create a great mobile banking experience!
Last week in London, I wanted to shoot a video, but it appeared that I had left my camera’s memory cards at home. On my previous trip, it had been my Android tablet that I had forgotten to bring with me. The trip before that, it was my stack of local currency, my power adapters, my sunglasses, or whatever, which I hadn’t properly packed.
Sure, I have a travel checklist. But clearly, it had turned into a checklost. With at least 50 confirmed upcoming events around the world, it was time for me to redesign it.
Four Preferred Places
My original checklist was one large unorganized list of reminders. This regularly led to problems because, by scanning the list too quickly, I easily overlooked an item that was buried among all the other things that I only knew too well. So I divided the checklist into four parts:
- Personal items (that I carry on my body)
- Shoulder bag
- Handbag (typically carry on luggage)
- Extra bag (typically check in luggage)
Each travel item on my improved checklist now has a preferred place. This not only helps to keep the individual lists smaller, and easier to check more carefully, but it also helps me keep things in the right bag. I don’t want to have that situation again where I thought I had my universal adapters or chargers packed in the other bag (but found out later that I hadn’t).
(And preferred means that items can change places depending on context. For example, my keys will have moved to my shoulder bag before I arrive at the airport, while my passport may temporarily move to my pocket while suffering the security and customs rituals.)
Standard versus Extra
Another thing I noticed messing up my packing efforts was that some standard items are by default in my bags (such as passports and adapters), other extra things are by default out of my bags (such as clothes and toiletries), and some items had a SchrĂ¶dinger-kind of existence, not clearly being in or out, until I opened my bags to have a look (such as device chargers and headphones).
After the reorganization, packing my bags with my improved checklist now consists of two distinct activities:
- Checking that all standard items are where they should be;
- Adding all extra items to the place where I want them.
Hopefully, this will save me some stress and headaches in the future.
For example, I once had to interrupt my trip to the airport because my passport was not in my bag: it was still under the scanner next to my computer. I always know that my passports are in my shoulder bag, except for the one or two times when, apparently, I was wrong. And thus, I made it a separate activity to check that I am not deceiving myself, thinking that the standard items are where they should be before adding all extra items. And a SchrĂ¶dinger-kind of existence is not part of the improved design.
And then, of course, there are the optional items that mainly depend on the weather forecasts. I remember once nearly freezing to death in Helsinki because I had no warm coat or gloves. I was once drying my clothes in my hotel room in London because, stupidly, I had brought no umbrella. And more than once, I have been sweating in the sun because I was silly enough to bring only dark blue jeans and long-sleeve shirts.
Short versus Long trips
Finally, things can always change a bit depending on context.
On short trips (one or two nights), I don’t need to take the larger bag with me. But this means I must jam any books, running gear, and clean clothes into my hand luggage, which is not always possible, or else just leave some of it at home. And on long trips (ten or more nights), the large bag magically changes into an extra large suitcase, and this also changes what I can bring with me (usually a lot more clothes).
Well, there you have it: the philosophy behind my new-and-improved travel checklist. I include the full list below (as it is now).
Is there anything missing that you have on your travel checklist, and that may be useful for me as well?
Shoulder bag – standard items
Credit cards and bank cards
Travel cards and loyalty cards
Pens and markers
Shoulder bag – extra items
Tablet + charger
Handbag – standard items
Spare underwear, socks, and shirt
Spare medicine, contact lenses
Handbag – extra items
Notebook + charger
Gloves, scarf, ear muffs [IF forecast = cold]
Umbrella [IF forecast = wet]
Travel clothes [IF distance = long]
Large bag – standard items
Large bag – extra items
Running shoes and clothes
Book / giveaway
Fleece jacket [IF forecast = cold]
Warm socks and sweater [IF forecast = cold]
Raincoat [IF forecast = wet]
Short pants [IF forecast = hot]
photo (c) 2013 Chris Lott, Creative Commons 2.0
My new book Managing for Happiness is available from June 2016. PRE-ORDER NOW!
When I work with clients, they often have a “problem” with product ownership. The product owners want tons of features, don’t want to address technical debt, and can’t quite believe how long features will take. Â Oh, and the POs want to change things as soon as they see them.
I don’t see this as problems.To me, this is all about learning. The team learns about a feature as they develop it. The PO learns about the feature once the PO sees it. The team and the PO can learn about the implications of this feature as they proceed. To me, this is a significant value of what agile brings to the organization. (I’ll talk about technical debt a little later.)
One of the problems I see is that the PO sees the big picture. Often, the Very Big Picture. The roadmap here is a 6-quarter roadmap. I see roadmaps this big more often in programs, but if you have frequent customer releases, you might have it for a project, also.
I like knowing where the product is headed. I like knowing when we think we might want releases. (Unless you can do continuous delivery. Most of my clients are not there. They might not ever get there, either. Different post.)
Here’s the problem with the big picture. No team can deliver according to the big picture. It’s too big. Teams need the roadmap (which I liken to a wish list) and they need a ranked backlog of small stories they can work on now.
In Agile and Lean Program Management, I have this picture of what an example roadmap might look like.
This particular roadmap works in iteration-based agile. It works in flow-based agile, too. I don’t care what a team uses to deliver value. I care that a team delivers value often. This image uses the idea that a team will release internally at least once a month. I like more oftenÂ if you can manage it.
Releasing often (internally or externally) is a function of small stories and the ability to move finished work through your release system. For now, let’s imagine you have a frictionless release system. (Let me know if you want a blog post about how to create a frictionless release system. I keep thinking people know what they need to do, but maybe it’s as clear as mud to Â you.)
The smaller the story, the easier it is for the team to deliver. Smaller stories also make it easier for the PO to adapt. Small stories allow discovery along with delivery (yes, that’s a link to Ellen Gottesdiener’s book). And, many POs have trouble writing small stories.
That’s because the PO is thinking in terms of feature sets, not features. I gave an example for secure login in How to Use Continuous Planning. It’s not wrong to think in feature sets. Feature sets help us create the big picture roadmap. And, the feature set is insufficient for the frequent planning and delivery we want in agile.
I see these problems in creating feature sets:
- Recognizing the different stories in the feature set (making the stories small enough)
- Ranking the stories to know which one to do first, second, third, etc.
- What to do when the PO realizes the story or ranking needs to change.
I’ll address these issues in the next posts.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
In Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way to get from the big picture to the ranked backlog is via deliverables in the form of small (user) stories.Â See the wikipedia page about user stories. Notice that they are a promise for a conversation.
I talked about feature sets in the first post, so let me explain that here. A feature set is several related stories. (You might think of a feature set as a theme or an epic.) Since I like stories the team can complete in one day or less, I like those stories to be small, say one day or less. I have found that the smaller the story, the more feedback the team gets earlier from the product owner. The more often the PO sees the feature set evolving, the better the PO can refine the future stories. The more often the feedback, the easier it is for everyone to change:
- The team can change how they implement, or what the feature looks like.
- The PO can change the rest of the backlog or the rank order of the features.
I realize that if you commit to an entire feature set or a good chunk for an iteration, you might not want to change what you do in this iteration. If you have an evolving feature set, where the PO needs to see some part before the rest, I recommend you use flow-based agile (kanban). A kanban with WIP limits will allow you to change more often. (Let me know if that part was unclear.)
Now, not everyone shares my love of one-day stories. I have a client whose team regularly takes stories of size 20 or something like that. The key is that the entire team swarms on the story and they finish the story in two days, maybe three. When I asked him for more information, he explained this it in this way.
“Yes, we have feature sets. And, our PO just can’t see partial finishing. Well, he can see it, but he can’t use it. Since he can’t use it, he doesn’t want to see anything until it’s all done.”
I asked him if he ever had problems where they had to redo the entire feature. He smiled and said,
“Yes. Just last week we had this problem. Since I’m the coach, I explained to the PO that the team had effectively lost those three days when they did the “entire” feature instead of just a couple of stories. The PO looked at me and said, “Well, I didn’t lose that time. I got to learn along with the team. My learning was about flow and what I really wanted. It wasn’t a waste of time for me.”
“I learned then about the different rates of learning. The team and the PO might learn differently. Wow, that was a big thing for me. I decided to ask the PO if he wanted me to help him learn faster. He said yes, and we’ve been doing that. I’m not sure I’ll ever get him to define more feature sets or smaller stories, but that’s not my goal. My goal is to help him learn faster.”
Remember that PO is learning along with the developers and testers. This is why having conversations about stories works. As the PO explains the story, the team learns. In my experience, the PO also learns. It’s also why paper prototypes work well. Instead of someone (PO or BA or anyone) developing the flow, when the team develops the flow in paper with the PO/BA, everyone learns together.
Small stories and conversations help the entire team learn together.
Small features are about learning faster. If you, too, have the problem where the team is learning at a different rate than the PO, ask yourself these questions:
- What kind of acceptance criteria do we have for our stories?
- Do those acceptance criteria make sense for the big feature (feature set) in addition to the story?
- If we have a large story, what can we do to show progress and get feedback earlier?
- How are we specifying stories? Are we using specific users and having conversations about the story?
I’ve written about how to make small stories in these posts:
- Make Stories Small When You Have “Wicked” Problems
- Three Alternatives for Making Smaller Stories
- Feature sets in How to Use Continuous Planning
- Reasons for Continuous Planning
The smaller the story, the more likely everyone will learn from the team finishing it.
I’ll address ranking in the next post.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
As a Customer Success guru, Iâve seen some exceptional implementations of LiquidPlanner over the past six years. Iâve also seen my fair share of notâso-great rollouts. And, it is safe to say that Iâve certainly noticed a few clear trends along the way!
There is no getting around it: The approach you take in your rollout is directly tied to whether your team will adopt LiquidPlanner in the long-term or eventually toss it by the wayside. How you plan, who leads the implementation, and how you communicate the why and how LiquidPlanner will be used are vital to success. Itâs worth getting these right the first time around.
Sharing recommended practices to help our customers be successful is one of my favorite parts of the job. So here it isâmy learnings on the key factors linked to not only a smooth rollout, but also long-term adoption of LiquidPlanner:
1. Identify a Champion
You need a Champion, really! This is the person responsible for rolling LiquidPlanner out to the team. They donât have to carry pompoms, but they do have to put on their Project Manager hat and treat your rollout like you would a project. As youâre sweeping your team for a potential Champion, youâll want to look for someone who can be both the subject matter expert and internal POC (Point of Contact) for all things related to your workspace â they should have a knack for helping users learn and get comfortable in the application during the initial rollout phase and beyond.
If you are running a large scale or complex implementation, one Champion wonât be enough. Consider having a designated group to manage your rollout to ensure one person isnât left with the lionâs share of the work. If not a group, youâll find that having at least a co-champion can be a saving grace.
In general, having a back-up POC for LiquidPlanner is a great practice â as it ensures that things wonât array when your Champion is beachside on vacation!
2. Get executive sponsorship
You can have a rock star Champion, but they can only do so much without support from upper management. Fully embracing a new tool requires buy-in from the entire team â everyone has to understand why LiquidPlanner was selected and the value it will bring in order to get through the change process it requires. And, your Executive Champion can provide the needed messaging to get everyone on board.
Executive-level involvement alone will convey that using LiquidPlanner is not a suggestion, but essential. This provides the roots for long term adoption.
3. Make theÂ LP PlaybookÂ the core of your implementation
In order to drive consistent usage and get reliable data, your team needs to use LiquidPlanner in the same way. Several key questions must be answered:
- Who manages incoming work and how is it triaged?
- How frequently must project contributors track time?
- Who sets priorities in the workspace?
- Who is responsible for setting the original estimates of work?
Once youâve addressed these questions, the business rules and workflows that have surfaced should be documented in a guide. We call this guide the LP Playbook and provide you a template to make your own! Â The best results Iâve seen are when the Champion partners with key stakeholders to define how users need to engage in the workspace, and your Executive Champion then promotes the LP Playbook.
It is important that this document communicates why your team will use LiquidPlanner; stating your goals and how this PM tool will help you achieve your department or company initiatives. When project contributors have a clear guide to reference it reduces uncertainty and any hesitation or fear of working in LiquidPlanner. The result: faster (and more!) engagement.
When thinking about your business rules, make sure that they support your goals in using LiquidPlanner. For example, if your objective is to better understand where your team is spending their time, tracking time daily would be a key business rule for you.
4. Architect a sound workspace structure, then hold a Kickoff meeting
The way you build out your package structure, project work breakdowns, and custom elements like activities and custom fields must align with your workflows and business requirements. Once your LP Playbook is complete and the workspace is ready, itâs time to invite in project contributors and formally introduce LiquidPlanner to the team.
Some of the most successful introductions Iâve seen involve a formal LiquidPlanner Kickoff hosted by the Champion and Executive Champion, where the team is gathered to walk through your workspace setup and LP Playbook. And, when excitement and buzz is still fresh, distribute your LP Playbook to the team for reference moving forwardâmandating the crystal clear expectations youâve outlined for them.
5. Carve out time for your rollout and donât lose momentum
Youâve all heard this before, but I have to say it again just for good measure:
Rolling out any new technology takes time and careful consideration. And while LiquidPlanner has a scheduling algorithm that is practically magic, it doesnât have the power to get buy-in from your team, hand them their LP Playbook, or architect your workspace for you. The reality is that time needs to be reserved to do these things and to do them right.
This is where your Executive Champion comes in to playâagain! They should ensure that your Champion has time in their day to dedicate to LiquidPlanner and to remain focused on the implementation over time. The last thing you want is to spend effort getting the rollout going only to put LiquidPlanner on the backburner due to higher-priority issues. Youâll want to keep a sense of urgency until your team is fully up and running in the workspace. If you lose momentum, your rollout will take a hit and this can negatively impact long-term adoption.
Remember, the way you implement LiquidPlanner can make or break long-term success. Having the right champions on board (who have time and arenât overloaded!), developing clear and positive communication around usage, and architecting a supportive workspace structure cultivates the roots needed for the consistent adoption that ensures youâll achieve your business goals. If youâre thorough and patient with your rollout process, your team will be up and running smoothly before you know it.
See Preparing for Liftoff for more on rolling out LiquidPlanner to your team.
Â If you want to learn more about onboarding and motivating your team to use your new project management tool, and how to approach other classic project management speed bumps, download our eBook: Â âHow to Solve the Top 9 Project Management Challenges.â
At Tasktop, we pride ourselves on not missing releases. We have not missed a release in over four years. And we release quarterly. That’s a pretty good record. As part of our releases, we hold internal release demos where the teams get to show off the new features they’ve added to the product. And we hold this end of release demo every 3 months without fail. There’s only one problem with the end of release demoâŠ
It’s as boring as watching paint dry.
I cringe to say that because we have some whip-smart developers who can work miracles. But it’s true. Our end of release demos were rough. Part of it is how our product is built. We help companies solve business problems by providing integrations between their software development tools. We build connectors to a variety of ALM, PPM and QA tools and we build the integration engine that serves as the hub for these connectors. A large part of our demos were structured around supporting new artifacts (stories, defect, requirements, etc) or fields (text fields, single-select fields, multi-select fields, etc). After a few years of showing one field synchronized to another field, it gets a bit predictable.
In some ways, we’re a victim of our own success. When customers first see what we can do, they’re amazed, but we see behind the curtain and know how the sausage is made. I don’t need to see another single select field mapped to a string field. If you’ve seen this for one tool, it’s not a stretch to understand that it can be done with another tool.
Even engineering became bored with our demos. When the people showing off the new stuff get bored with how they’re showing it off, you know something has to be done.
So six months ago, we hatched a plan.
ONE UNIFIED DEMO
We decided to create one unified demo that shows how our new features solve an actual customer need. Instead of five development teams each presenting their own stand-alone demos that had nothing to do with each other, we would now have one unified demo across the entire engineering team. The Product team would be in charge of developing a demo story that could be told using the features developed in this release. Not all the team members would demo. And more importantly, not all the new features would be demo’d in the end of release demo. Some features may be too small or may not fit the demo scenario. Besides, we already record all the Sprint demos, so if you really need to see something in action, check out the team’s sprint demo.
People loved it.
We’ve only gone through this twice, but it’s going great. The response from engineering as well as our other internal stakeholders was immediate and clear. We had glowing emails coming in within minutes of our first go with this new demo process.
Instead of the demo being a lot of disconnected standalone features, it became one comprehensive story. It also became much faster. Instead of taking the traditional 2.5 hours, we slimmed it to under an hour.
Most importantly it demonstrated to everyone that we make ONE SOLUTION that solves serious problems. We may have multiple products with various features, but at the end of the day, they are used together to help businesses deliver better software faster. Creating a demo story that explains to our stakeholders what customer problems we can solve today is incredibly powerful.
We have a few additional action items:
- Be more specific in pointing out the new stuff.
Now that demos are a holistic story, they incorporate both existing and new features. We need to do a better job of pointing out in the demo “this is new functionality”.
- Start the process earlier.
We can craft our demo story almost as soon as we finish our release plans. That gives the teams almost three months to prepare. That way, engineering will know from the very start of the release, what features will be presented at the end of the release.
- Shorten the scheduled time for the demo.
After this most recent demo ended, the entire engineering organization looked around like, “what do we do now?” There was over an hour still on the schedule for demos. That was a holdover from our old process. We can now schedule other events and simply give people their time back.
It’s not every day you can give yourÂ organization over a person-week of time back, but we did it with this new demo process. Tasktop’s mission is to help companies deliver software better and faster, it only makes sense that we continue to strive to improve our own processes.
Do you think that your project should have a âlaunchâ event? In this extract fromÂ The Science of Growth*, Sean Ammirati shows that a single, formal big launch isnât always what kickstarts a company (or a project) into the big league. What really works might surprise you – it’s definitely something to work on when you are thinking about positive project risk! Enjoy…
A founderâs core vision, in hindsight, will typically look obvious. However, at the time the founders embark on their journey their vision is often a truth that many others donât yet realize. Itâs therefore tempting to think that the key to success is to find a big enough stage or platform on which to unveil your solution. However, as students of the lean entrepreneurship movement hear repeatedly, itâs usually not a good idea to launch your product with a âbig bang.â This is solid counsel from my experience.
Although this is solid counsel on day one of a startup, it may not be such sage advice later on. One thing we repeatedly noticed in our study, across many of our chosen companies, was that some successful startups built awareness by drafting off larger events to catalyze growth once they had completed the four prerequisites described in section one.
Later, many of these events seem to be considered the startupâs âlaunch,â advancing the misconception that a big bang launch is a prerequisite for success. In none of the companies we analyzed is this more apparent than Twitter.
Iâve been attending the South by Southwest (SxSW) conferences since before Twitterâs breakout year in 2007. And every year since 2007, journalists rush home to talk about the next thing to launch at SxSW, and ask whether [insert startup name here] is the next Twitter. Itâs a great narrative for these journalists, especially when you consider Twitter is today worth over $21 billion. This story of SxSW launching Twitter has dramatically increased the popularity of the SxSW Interactive Festival and become startup folklore.
Unfortunately, itâs not actually true that Twitter was launched at SxSW. As described by Evan Williams on Quora, here is what actually happened (emphasis mine):
. . . contrary to common belief, we didnât actually launch Twitter at SXSWâSXSW just chose to blow it up. We launched it nine months beforeâto a whimper. By the time SXSW 2007 rolled around, we were starting to grow finally and it seemed like all of our users (which were probably in the thousands) were going to Austin that year. So, we did two things to take advantage of the emerging critical mass:
- We created a Twitter visualizer and negotiated with the festival to put flat panel screens in the hallways. This is something theyâd never done before, but we didnât want a booth on the trade show floor, because we knew hallways is where the action was. We paid $11K for this and set up the TVs ourselves. (This was about the only money Twitterâs *ever* spent on marketing.)
- We created an event-specific feature, where, you could text âjoin sxswâ to 40404. Then you would show up on the screens. And, if you werenât already a Twitter user, youâd automatically be following a half-dozen or so âambassadors,â who were Twitter users also at SXSW. We advertised this on the screens in the hallways. (I donât know how many people signed up this wayâmy recollection is not a lot.)
I donât know what was the most important factor, but networks are all about critical mass, so doubling down on the momentum seemed like a good idea. And something clicked.
When we look through the cases weâve analyzed, this pattern of a product or service launching and then later having a big event âto blow it upâ appears to be common. As we started looking at these later events, we started calling them a âdouble triggerââthe first trigger was getting the product in the market and getting feedback, but this second event was the double trigger that ultimately catalyzed growth. Iâd like to highlight three types of events that can have this catalyzing impact.Double Trigger Type 1: Something Happens to Your Product
In December 2005, Saturday Night Live aired a digital short called âLazy Sundayâ starring Andy Samberg and Chris Parnell. The video was a hit on SNL and was uploaded to YouTube shortly after it aired. While eventually the video was pulled at NBC Universalâs request (for copyright reasons), this didnât happen until February, after over seven million views of the video on YouTubeâs service. When website analytic vendors like HitWise plot the growth of YouTubeâs traffic, you can easily see the day in December 2005 when âLazy Sundayâ started accelerating growth dramatically. That increase in growth wasnât short lived, but in fact continued from that point forward.
Based on that impact, Rick Cotton, chief counsel of NBC Universal, argued at an industry event that NBC ultimately made YouTube worth $1.5 billion. While that seems a bit extreme, the popularity of âLazy Sundayâ certainly catalyzed YouTubeâs growth. As a reminder, at the point Rick Cotton made the claim, Google had recently acquired YouTube for $1.5 billion.Double Trigger Type 2: A Big Event Needs Your Product
In 2008, the Democratic Party made the decision to move Obamaâs speech at their convention in Denver from the Pepsi Center (capacity 18,007) to the larger outdoor venue of Invesco Field (capacity 76,125). The decision immediately created logistical challenges, as there simply were not enough hotels in Denver to handle the expected additional visitors, but it created a catalyst for Airbnb.
Later CNN Money reported on that accommodation crisis moment:
For Airbnb co-founder Brian Chesky, that was a Eureka moment.
âWe were thinking to ourselves . . . light bulbâs going off,â he said. âThatâs where theyâre going [to] stay: Theyâre going [to] stay at Airbnb homes.â
In a matter of weeks, hundreds of people started listing their Denver apartments on Airbnb for visitors to rent. Airbnb allows users to rent out everything from an extra room to a separate home.
âHad it not been for the DNC, itâs hard to know what Airbnb would be today,â Chesky told CNNMoney. âThese things, itâs hard to get them going and you need a big kind of pop.â
While LinkedIn held off on all PR until it had 40,000 members and had already raised its first round of institutional financing from Sequoia Capital, once the company started its PR, it used a similar strategy to Airbnb. Instead of focusing on the overall service and how it worked, LinkedIn would pitch reporters on stories about members who found a job through LinkedIn. The company also rolled out the PR primarily through local media channels and focused on successful job searches in the home city of the reporter to whom the company was making a pitch. This allowed LinkedIn to present the value of its platform and the LinkedIn experience to the press as something much more concrete.Double Trigger Type 3: A Competitor Makes a Mistake
Sometimes the event that acts as a catalyst is actually a misstep by a competitor. To me, the case of Movable Type vs WordPress is actually one of the most interesting examples of an event catalyzing growth. Specifically, Movable Typeâs May 2004 decision to change the terms of its license.
In a Forbes magazine story eight years later, reviewing WordPressâs early history, author J. J. Colao explained:
In a field dominated by Movable Type, their service [WordPress] attracted thousands of users through word of mouth. After Movable Typeâs owners decided to charge users in 2004, WordPress attracted a deluge of incensed refugees fleeing the company. By that August WordPress boasted 15,000 users and a pack of loyal developers refining code for free around the world.
As Movable Type Product Manager Byrne Reese explained in his blog postmortem later:
. . . what users feared most of all, is a repeat of exactly what happened the day Movable Type announced its licensing change: one day waking up to the realization that you owe some company hundreds, if not thousands of dollars and not being able to afford or justify the cost monetarily or on principle.
Itâs clear that Byrne is absolutely right. When you go back now and look at the early reaction, that fear is clear, and WordPress definitely used it to their advantage. For example, Ari Paparo, now a startup CEO and at the time an Internet marketing consultant, wrote a post titled âTime to Update the PowerPointâ in which he said:
As part of my consulting work Iâve implemented several corporate blogs, both as intranet and external solutions. In every case, I pitched some of the big advantages to MT:
- Low cost license
- Flexible, no restrictions
- Easy to create multiple blogs
- Easy to add new users
Well, thatâs all shot to hell.
It would be easy to misinterpret the recommendations of this chapter as: Just work hard and hope you get lucky with a large event. Instead, I think you need to take the steps described to look for opportunities to exploit.
Excerpted with permission by St. Martin’s Press from The Science of Growth: How Facebook Beat Friendsterâ and How Nine Other Startups Left the Rest in the Dust by Sean Ammirati. Copyright 2016.
* This article contains affiliate links.
You'll also like:
- Launch of Project Management in the Real World! I heard from the publishers today that the first copies of Project Mangement in the Real World have come off the press and are looking...
- The Science of Growth [Book Review] Do you work in a startup, or digital project management? This might be the book you are looking for. It explains why some companies take...
- PRINCE2:2009: The Launch Please be patient with the video: it takes a while to load.Â More notes from the launch event will be here in the days that...
- Project Management in the Real World launch The kind folks at the British Computer Society are throwing a bash for me to launch my new book, Project Management in the Real World....
- Launch in the city Remember the new London womenâs networking group, WeAreTheCity?Â Their launch event was a huge success:Â hundreds of women queuing around the Monument branch of House...