The bottom line: Find something to say. Write good stuff. Get known. Be proud of your work. Be creative in your own marketing.

Presenters

Pam Slim

Kate Lee

Stephanie Klein

Guy Kawasaki

Hugh MacLeod

Date

Tuesday, March 17

“Make the kind of happy that no one can take away.”

Blogs do not have a flow like a book, so while you can start with the content of your blog as talking points, there is a lot of work involved in creating a book. Craft a book out of your blog writing. Just like there are differences and advantages to the web medium (where the print medium cannot go!), the same is true for the print medium.

Blogs build relationships with other bloggers/authors. These are key.

Agents and Publishers

Context helps when meeting an agent–who are the kinds of writers who share your potential audience? But it can be more important who knows about you. Reach out to people you genuinely admire. Get known. But once you’re there, you have to be ready to sell the idea. Write a good query letter (talk in marketing speak and write in your own voice at the same time) that represents you and your work. Two types of writing opportunities: the great Voice, or the fantastic Idea.

Share genuine relationships that you have built. Demonstrate the way you are connecting with other writers and your audience.

These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.

• When designers push their vision out to “version 10″, it can cause tension with developers who are usually starting from the other end (i.e., Agile). Developers want to start small (and efficient/elegant) and progressively build toward a design. Balance is key.
• The best possible thing a designer can do for a developer is to share the problem and challenges, not just ask for a composed feature. That way the designer is asking to partner on the solution with the developer. Happiness ensues.
• The best possible thing a developer can do for a designer is to communicate principles and needs to designers to create a more common ground. For example, talking to designers about considering both real-time interactivity and asynchronous actions.
• The best possible thing both can do is hang out with each other outside the office.
• Build trust.

For the rest of the notes, I depend on my trusty Michigan friend, daniel slaughter. He takes amazing notes.

These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.

Why is everyone more interested in the answer than the question?

When you have a problem that needs to be solved, you should be more interested in the questions than the answers. Solutions come from good questions, not prepackaged answers. I know you are pressed on every side and feel like you do not have enough time to worry about good questions. But good questions now, will save you exponential time in the future. If you allow many small under-pressure-solutions to stack up, you end up with a building that cannot be repaired, but can only be torn down and rebuilt.

There is a tendency in my field to provide a set number of answers, rather than taking time to consider the questions with people. I look forward to the day when we feel like we have time to ask the best questions and consider the best answers.

Blame Darwin

Humans solve problems naturally to survive. We get a buzz from talking about solutions. The solution is viewed as “taking action”, and we like to feel like we are making progress. But if we do not pause and ask specific and thoughtful questions about the problems we are facing, we have no way to judge what is an important problem and what is just small potatoes. Without a defined problem, we’re depending on trial-and-error and can only learn in hindsight. When it comes to survival of the fittest, and you are the one attempting to solve the problem of the saber-toothed tiger in front of you and you can only grab a rock if one is fortunately nearby, hindsight is usually moot after about 3 seconds.

Problem definition questions are specifically built to get us to be less dependent on hindsight (and beat evolution!). Not only do they help us select the best solution, they get clients to focus on defining the problem instead of the solution. I have had many projects begin with a client coming to me with a pre-selected solution that they want me to implement. As a solution-builder, that pretty much ties my hands and prevents me from using all of my experience and training. It seems just as ludicrous for me to tell someone else what their problems are; why should my client tell me which solution I should implement? The roles are crossed. The client is the expert (whether they know it or not) in defining the problem. I’m the solution expert. I’m not doing anyone any favors by taking the first solution presented without asking questions designed to better define the problem.

One hat, two hat, green hat, blue hat

Edward de Bono’s Six Thinking Hats talks about the importance of questions as an initiation to any problem-solving exercise. I’ve paraphrased a few of his questions into a list that usually helps jump-start a problem discussion:

• What is the current state of affairs, and what problems does this current state cause?
• Who is affected by those problems?
• What are we trying to ultimately change or achieve?
• If we solved all those problems, how would the world be different?
• Who controls the systems affected by these problems?
• What is the risk involved in attempting to solve these problems?

By answering these questions, we both comprehensively define the specific problems we’re trying to solve and set ourselves up with a way to check for success. Without investigating the problem, we have no way to do a good job of measuring our level of success. We just implement things without any metric that tells us if it was a good idea after all.

Talk to the hand

The challenge I see is not getting people to read this blog and think it is a good idea. The challenge arises the next time someone comes to me with a solution they need me to implement. I have to convince them it is a good idea to pause, backtrack, and define the problem when all they want to do is just get a solution in place. People tend to sing a different song when it’s their problem that needs to be solved.