- How do you persuade? I find that Iâ€™m more successful in persuading someone when I acknowledge strengths in alternatives while demonstrating a superior choice. Sometimes it may truly be the case that the only other alternatives are poor (or even non-existent); however, the more time goes by, the more alternatives become available. Superior choice may come from compelling feature sets, fantastic user experiences, exceptional service post-sale or all of the above. You cannot effectively articulate superiority, though, if you donâ€™t know your audience (i.e. the customer). They say you donâ€™t really know until you can teach. You canâ€™t really persuade until you can paraphrase the need of the other. I want your long-term commitment to my products and services. A quick sell (hasty persuasion) does me little good over time. Valuable transactions like reference-based sales and forms of viral marketing never take hold. Basically, I agree with Robert Scobleâ€™s authority method of persuasion (i.e. Iâ€™m an authority and Iâ€™m looking out for your best interests). My point is that you have to know what my interests are before you can make this a persuasive statement.
- I guess that Iâ€™m an edge case when it comes to screen resolution. Vibe: Todayâ€™s edge case is tomorrowâ€™s mainstream user.
- Paul Vick updated a good Top 10 list of application performance rules he wrote several years ago. Vibe: Rule #6: 90% of performance problems are designed in, not coded in. Paul
responds to some criticism toward his rules, too (via Chris Anderson). Another good post on performance tuning comes from Rico Mariani: Bad Analysis Worse Than None.
- Joel Spolsky offers Top Twelve Tips for Running a (Technical) Beta Test.
- Harry Pierson learns that he really needs Documentum.
- Occasionally I enjoy watching Charlie Roseâ€™s interviews on PBS. Now I can listen to them while I work.
- Why RSS is better than email and is more productive than the web.
- Nine women canâ€™t have a baby in one month. This post from Michael Earls reminds me of the start of my software development career at a large defense contractor. Although our deliverables were all software, management often came from a hardware background. (There was significantly more hardware being built and shipped than software.) All too often, management would throw more bodies on a problem, expecting the results in 1â€™s and 0â€™s to follow widget production on an assembly line. Instead, the result was often further schedule delay and quality issues. As I recall, the business term core competency came into vogue soon thereafter, and the company slowly realized that pure software wasnâ€™t one.
- In another post, Michael asks a good question: Do you believe in your product? Vibe: If I believe in it, then I am passionate about it. If I am passionate about it, then I will make it happen, no matter what challenges Iâ€™m faced with. If I donâ€™t believe in it, Iâ€™m more likely to give up on it and just let it die.
- Thanks to Don Box for the pointer to this HyperCard eulogy. One of my first summer internships during college was to produce a graphical office/conference room locator for a five story office building using this product.