Information Pull vs. Push
Product development teams can quickly get buried in information, and it seems like the amount of information passing around grows exponentially the closer a product moves towards release. To help relieve the burden of information overload, I often recommend moving from information push to information pull. "Pull" is one of Jim Womack's fundamental principles of Lean because this simple concept permeates a Lean organization, including its information systems.
Push systems dump stuff on the recipient with no regard for when it will be needed. Email (especially those emails that include dozens of people on the cc: list) are inherently information push systems. As a recipient, I have no control over when or how the senders send information. I may have needed the information yesterday, or I may not need the information for months. No matter - it all ends up in my inbox where I have to figure out what to do with it.
Pull systems make stuff available to the recipient when the recipient is ready to receive it. Blogs are inherently information pull systems. I post content to my blog, and then with almost no intervention on my part, my readers can get this information when they want it in the frequency and form that works for them. Some want an emailed digest, others just want to visit the home page periodically via a bookmark. Those with RSS readers can subscribe to one of my feeds, and pull the content on exactly the schedule that works for them.
I lose a little control. When I post something, I have no idea when you receive it because it depends on your schedule, not mine. When I talk to one of my readers on the phone, I don't know whether or not they've seen the thing I posted that morning. It's a small price to pay for me to know that when you do pull the information, you have chosen to do so at a time and place that works for you. It's waste for both of us if I send you an email that goes straight to the trash so that you can get to the 499 other emails you received that day. Information pull systems also require that we assume that our recipients are grown-ups responsible for their own information needs. "I didn't get the memo!" is no longer an excuse when the memo was posted to the team's web site on time.
I'm not advocating that product development team members start blogs - although an internal team blog with its own RSS feed might be a good way to provide simple updates. I am suggesting that they think about ways to use their web sites and collaboration tools such as SharePoint® to provide information to people who need it at the moment that they need it in the form that works best for them. We use emails because it's the path of least resistance. It's quick, easy and we know that it will get at least a few seconds of attention before it's deleted. How can we create pull systems that are just as easy to use?
Push systems dump stuff on the recipient with no regard for when it will be needed. Email (especially those emails that include dozens of people on the cc: list) are inherently information push systems. As a recipient, I have no control over when or how the senders send information. I may have needed the information yesterday, or I may not need the information for months. No matter - it all ends up in my inbox where I have to figure out what to do with it.
Pull systems make stuff available to the recipient when the recipient is ready to receive it. Blogs are inherently information pull systems. I post content to my blog, and then with almost no intervention on my part, my readers can get this information when they want it in the frequency and form that works for them. Some want an emailed digest, others just want to visit the home page periodically via a bookmark. Those with RSS readers can subscribe to one of my feeds, and pull the content on exactly the schedule that works for them.
I lose a little control. When I post something, I have no idea when you receive it because it depends on your schedule, not mine. When I talk to one of my readers on the phone, I don't know whether or not they've seen the thing I posted that morning. It's a small price to pay for me to know that when you do pull the information, you have chosen to do so at a time and place that works for you. It's waste for both of us if I send you an email that goes straight to the trash so that you can get to the 499 other emails you received that day. Information pull systems also require that we assume that our recipients are grown-ups responsible for their own information needs. "I didn't get the memo!" is no longer an excuse when the memo was posted to the team's web site on time.
I'm not advocating that product development team members start blogs - although an internal team blog with its own RSS feed might be a good way to provide simple updates. I am suggesting that they think about ways to use their web sites and collaboration tools such as SharePoint® to provide information to people who need it at the moment that they need it in the form that works best for them. We use emails because it's the path of least resistance. It's quick, easy and we know that it will get at least a few seconds of attention before it's deleted. How can we create pull systems that are just as easy to use?
Labels: information, pull
posted by Katherine Radeka
at
12:14 PM
0 Comments:
Post a Comment
<< Home