Innovation Is About Arguing

This is a beautiful explanation. Every time that I work with a new product manager or business owner I always explain that I ask a lot of questions. When we are working together, I am going to explore the constraints and boundaries of the problem. When I explain it that way they do not feel that I am just being argumentative. Continuum has done a nice job of embedding this into their process and culture. Entering cultures that do not do this is a challenge because many people are sensitive to feeling a question is challenging their work.

On the point of say “no, because,” I try to avoid “no” in many cases because it is so final. I rather say “what about …, what do you mean …, I thought it was …”

I have worked with individuals and teams where we do these 5 things and it does help explore the solutions space. It is a mindset that all team members need to have to work. For many, the suspension of disbelief has to be requested so that they can go through the process and learn to trust the questioning/arguing for the purpose of exploring the solution space.

Innovation Is About Arguing, Not Brainstorming. Here’s How To Argue Productively by Daniel Sobol

    Breaking down hierarchy is critical for deliberative discourse.
    No is a critical part of our process, but if you’re going to say no, you better be able to say why.
    This model works for us because deliberative discourse requires a multiplicity of perspectives to shape ideas.
    Argument is productive for us because everyone knows that we’re working toward a shared goal.
    Our work requires intensity, thoughtfulness, and rigor. But no matter the nature of the project, we keep it fun.”


Big Data Analysis

This article makes the case that with the increase in data, there is a greater need to make decisions on the data and therefore a need to better represent the information for human consumption and decision making.

“Manually analyzing data is time consuming but is often done in order to maintain core business capacity, operational continuity, competitive advantage and compliance. Reviewing stacks of numbers and text is not only error prone but also makes it difficult to analyze data in order to:

1) Develop or assess a hypothesis: Those managing regulatory compliance may need to consider and assess a hypothesis like Hyman Minsky’s financial instability hypothesis to protect their firm’s future.
2) Discover errors and outliers: From a risk and compliance standpoint, a firm may want to find a way to easily monitor risk exposure across a portfolio on a trade-by-trade basis and manage outliers or trades that are over certain limits.
3) Map trends: From an investment management perspective, a firm may want to track volatility across sectors or industries to capitalize on market opportunity.
4) Create categories: A valuation and risk group may want to know if it can readily quantify exposure to all counterparties by subsidiaries.
5) Make decisions: A structured products group may want to know if it can create “what if” stress scenarios and decide on optimal product selection.
6) Understand relationships, such as spatial hierarchy and rank: For energy traders, the need may be to determine if a company can manage pipeline operations and portfolio optimization across crude, refined, natural gas and other commodities.
The need to effectively and efficiently address these concerns, individually or in combination, is a challenge for many firms. Following a thoughtfully crafted method to hone the possible visualizations choices is a good way to identify the most appropriate one. ”
By Julie Rodriguez and Francesco Brullo

The product design sprint

The product design sprint: a five-day recipe for startups – Jake Knapp/Design Partner, Google Ventures

Day 1: Understand
Dig into the design problem through research, competitive review, and strategy exercises.
Day 2: Diverge
Rapidly develop as many solutions as possible.
Day 3: Decide
Choose the best ideas and hammer out a user story.
Day 4: Prototype
Build something quick and dirty that can be shown to users.
Day 5: Validate
Show the prototype to real humans (in other words, people outside your company) and learn what works and what doesn’t work.

Lean design for entrepreneurship

I was reading about and watching some Youtube videos about lean entrepreneurship. The ideas that were in there are not much different from what you encounter in some of the conversations about agile and lean software development. With each of these things there seems to be something missing. Because the whole idea of lean is that you start with an idea and you create multiple prototypes. You learn from the prototypes and then you keep building.
The problem I have with this process is: how do you know if the idea you begin with is the correct idea?

It seems to me that is an awfully costly endeavor to go and build a prototype on the wrong idea when there are many cheap and efficient ways to find a better idea. Industrial design and inventors, for hundreds of years, have been doing different ways of generating and narrowing down ideas.Typically design uses the concept of going through sketches and small prototypes, comparing those sketches to each other to see what works and what doesn’t work in each of the sketches.Narrowing it down to those that you want to prototype and then you build from there.

You should be able to create different levels of prototypes. Lo-fidelity prototypes is the term used in design. These prototypes maybe on paper, blocks of wood, clay or a simulation. With these prototypes, you can create them and bring in front of a potential users and get feedback without a huge amount of costs and time in order to do it. This process reduces costs and and time involved in order to test the solutions put forth.

The process of lean entrepreneurship would be much more efficient and much more cost-effective if sketching and lo-fidelity prototypes were used in order to get to what lean refers to as a “pivot.” You should be able to pivot before you build.You don’t need to pivot as you build it. Pivot earlier and quicker in the product creation. Weed through the ideas that do not work before building working products. This will reduce the number of product pivots when you’re building your business model or your delivery mechanism.

You’re going to want to iterate on your solution in order to hone it for the users you want to go after. But you should be able to figure out how to prototype and to go through different solutions in the space in order to pick the best ones.

For most aspects of human performance when you measure and plot out the population of different things that humans can do, whether it be how quickly they can type or what are the best ideas they can come up with, if you plot them they would plot on a normal curve. If the plot is on a normal curve that means that the center of the curve is where most people reside. So if you pick an idea, how do you know whether or not your idea is sitting to to the left of middle or that your idea is not the worst idea. At this point, you are going to take this idea and start doing lean development so that you can slowly find out that your idea is not the correct idea.

If you follow design methodology, you should be able to go in and play the numbers game early. I have to imagine as an investor, if you’re investing in different companies the reason why you invest in many companies is because you want a better opportunity for success. You are hoping that somewhere along the line that one of the companies in your portfolio has success and has a lot of success. What you do is go through many different companies and many different ideas.

With sites like Mass Challenge and these places where they have people focus for a three-month period, they have hundreds of people and they compete against each other. Hopefully in the in the end your contest winners end up being the successful companies. You watch them compete, you watch them succeed or fail at whatever they were trying to to do. You want them to succeed early and quickly with little investment put into it.

If that is the case, then why would you build first to see whether or not your idea works? Why don’t you go through the process of sketching, ideation and storyboarding? Go from story-boarding through prototyping. You should be able to go from hundreds, if not thousands of ideas, narrowing it down to to tens of ideas that you would storyboard out from beginning to end. Then you should be able to take the storyboards and test them and narrow it down to three ideas that you want to to prototype.

During this process you should be validating each storyboard and design with your potential users. You should be able to go and engage them and find out whether or not your ideas even work for them. You should be able to narrow down to your three ideas that you think have legs.

In order to move forward, now you go through the lean process. Now you go in and start developing these 3 ideas rapidly. Pick your minimal viable portion of the solution. You put it out there and get the people that you have involved using it. See how much traction you get on each. You should be able to run your comparison between these three different ideas in order to get statistics and numbers back. Use these numbers in order to understand where you go.

Overall the the lean process makes sense but it will make more sense when you’re in the development phase. It doesn’t make sense when you’re trying to decide which idea and which solution is the best solution to work with. Lean starts off with an idea and or a variation on an idea, tests the two of them, and then iterates upon it it. You have to assume then that your idea is the best idea in order to begin. If you are an average human being, like most people are, then you will create average ideas and you need to work out the kinks before you bother starting your development. So create many ideas, sketch them, storyboard them, keep on comparing them, narrow them down, bring it down to 2 or 3 ideas that are the best ideas. After you compared and contrasted all the ideas and storyboards that you have, select the best ideas and start your lean process.

Cyclical nature of design in a software company

How do you handle the cyclical nature of design in your company? Every software company I have been in, the design projects are like a snake swallowing its food whole. One big project pushes through and then you just have to wait for it to digest.

The projects come in the beginning of whatever cycle engineering has whether it be 6mos, a month or 2 week sprints. Everyone wants some design but not everyone is ready. One team is ready and a big push is made. Research, analysis and design are done simultaneously as the team starts up again. Everyone is learning, everyone is ramping up and the push for the designs is made.

Taking on one, two or maybe three teams at a time is about all that one person can take on and do a good job. After the design is put forth work is needed to make production versions of the features developers are going to work on.

So the work shifts between user analysis and visioning, product analysis and simplification and inline production work. Visioning and simplification are intensive design efforts in short bursts and the inline productions are routinized and drawn out. Since engineering tends to be the larger and schedule driven part of the organization, all the design work is done in their cycles. Most companies I have worked for align all their development teams on the same cycles so you get peaks and valleys.

Would companies hire a design partner that trains and staffs themselves with designers? A design partner that creates a deep bench that can meet the peaks and lows as needed. Create a permanent relationship as if we were your only designers however we keep the designers fresh, interested and invested by constantly providing the feast and scheduling around the quiet times.


Help in many of the applications I use are pretty clunky and have not changed much in years.
Jack Moffett posted 3 articles of what he learned from how complex games provide help.

  1. No one reads help – integrate your tutorial – make it so the user can learn the product as they are working on their own tasks.
  2. Keep things moving along – provide information as the user waits – provide basic information during load times about a feature or functionality that may be of interest to them given what they are doing
  3. Provide something the first time – provide the help just when they need it – explain the feature the first time they encounter it, do not show the information the next time they use the feature

This requires thinking about the UI architecture ahead of time. The application needs to be designed to keep track of what the user is doing, the number of times they have encountered a feature, and the context of his work.

Many times help and training are separate from each other as well as from the design process. Doing these things make documentation and training integral to the user interface design and the overall experience.

My work in the news

Sometimes it takes so long in an enterprise software company to see the fruits of your work. Here is one case for me. Portfolio+ is the white label of the product I worked on here for the first year. My job was to clean up the navigations and make the product usable. At a minimum the financial advisors should not have to use help or the call center.

“Among Portfolio+’s requirements were high performance and reliability, and the system had to be fairly intuitive, says Driscoll, adding that financial advisers may not have time to read a manual. “A lot of time and energy was spent making sure it’s intuitive and well supported,” he relates. According to Merrill’s Sabbia, who says adoption has been successful, as part of the functionality bucket requested by financial advisers, tax-sensitive strategies and usability were both emphasized.”

“Citing the system’s flexibility, speed and the ability to bundle trades, Jay Fields, a financial adviser with Merrill Lynch Wealth Management in Freehold, N.J., says Portfolio+ has helped boost his productivity. “This is really the best-in-class from all the products I’ve seen,” contends Fields, who joined Merrill last year after 18 years with Morgan Stanley Smith Barney. As a senior portfolio manager, Fields uses Portfolio+ every day for portfolio trading. “When I get my work up and running in the morning, I open this up in an Internet Explorer window. It’s one of the first or second things that I have in front of me, and it’s out there all day long,” he says. “There are less steps involved in having to get trades done.”

Here is the whole article:

Enterprise Software could really learn from Instagram

Shouldn’t all interactions be instantaneous?
Why wait for the app to do what it wants.
“give the Instagram user a feeling of responsiveness, even when someone’s phone is trapped on a lousy connection.

  1. Instagram Always Pretends To Work
  2. Loading Content Based On Importance, Not Order
  3. Anticipating The User’s Every Move”