Wednesday, July 29, 2009
Getting started with Open Innovation
I'm listening to a a fireside chat (sans the fireplace) on Innovation at the Stanford Summit. Mitchell Baker, Chairwoman for Mozilla Foundation (one of the best open-innovation success stories) just gave some great advice to companies who want to test-drive open innovation. Choose a project or product where you can afford to have innovation. Innovation is messy, and open innovation means you have to be ready give up control. If you pick something that is close to your core, you'll frustrate those participating when you reject ideas for reasons you can't share. Pick a place in your business where you can afford to give up some control.
Tuesday, June 2, 2009
What do you need to be open to?
From time to time, someone asks me "what makes a good consulting client?"
What I realized recently is that it's up to us (we consulting/outsourcing/services companies) to be able to articulate who is or isn't a good client. Let's face it - not everyone is a fit to work together.
A couple of weeks ago I attended a marketing seminar by Tom Batchelder. He had us work through a messaging exercise called "Pain-Opportunity-Open To" that helps you orient your messaging to what really matters to your customers:
For us, our customers need to be open to:
Can anyone tell me - what kind of product does that work on? How can you have a successful product, when some of your team doesn't even know the context in which it will be used, let alone who will be using it?
If you're embarking on hiring an outsourcing or consulting partner, and they haven't articulated who their best customers are, and what they need to be open to, now is a good time to ask. Trust me, now is a much better time to learn that then two weeks before a deadline.
What I realized recently is that it's up to us (we consulting/outsourcing/services companies) to be able to articulate who is or isn't a good client. Let's face it - not everyone is a fit to work together.
A couple of weeks ago I attended a marketing seminar by Tom Batchelder. He had us work through a messaging exercise called "Pain-Opportunity-Open To" that helps you orient your messaging to what really matters to your customers:
- Pain: What pain are your customers in when they hire you?
- Opportunity: What are your customers loooking to acheive when they hire you?
- Open To: What must they be open to if they are going to be a good fit for doing business with you?
For us, our customers need to be open to:
- sharing control of the product development process
- new ideas and new ways of doing things
- sharing everything they know about the project - the risks, what will make the project a success, what peripheral information we should know, what the priorities are, who the customers are...
Can anyone tell me - what kind of product does that work on? How can you have a successful product, when some of your team doesn't even know the context in which it will be used, let alone who will be using it?
If you're embarking on hiring an outsourcing or consulting partner, and they haven't articulated who their best customers are, and what they need to be open to, now is a good time to ask. Trust me, now is a much better time to learn that then two weeks before a deadline.
Wednesday, April 1, 2009
Macadamian wins new project in the financial industry
I'm thrilled about the announcement we made this morning about a new project we're doing in the financial sector. I think it's going to help turn the global economy around:
http://tinyurl.com/co5oma
http://tinyurl.com/co5oma
Tuesday, March 31, 2009
Moulding young minds
I had a conversation this morning with Sylvain (our Director of Process Improvement) that connected some dots.
A few weeks ago, someone asked me - who are the people in your life that inspired you and shaped your path? Then they said - you are that person now. The things you say, and how you act inspires others around you, and has an impact on the path they take.
One of our missions at Macadamian is to inspire young students to pursue a career in technology. We believe that if we don't get students excited about technology and design, we're going to have a serious shortage of designers, engineers and computer scientists in the next couple of decades, and we're going to lose our innovation edge. So, we're one of the founders of the Ottawa High School Technology Program, and we recently invited in 3 high school students to work with us for a semester, because we think we can make a dent, and help reverse the trend of dwindling engineering enrollment.
Sylvain and I were talking about what we'd like our students to work on, and we decided that it was important to us that what they work on not be grunt work, but be a project that has an impact for Macadamian, and be something challenging. We'll mentor them through it over the course of the semester, so that they come away with the experience of working in a software company - from there they can decide if this is the career they want to pursue. Someone gave me that opportunity when I was in high-school - to do real, impactful work when I was on a high-school co-op term, and that has stayed with me since.
So here's the takaway - for most of the people reading my blog, I'd bet you continue to seek out mentorship, but also have an opportunity to mentor others. Take a chance and invite in some high-school co-op students, give them the chance to do real work, give them guidance, and you might be surprised about what you learn and what kind of impact you can have.
A few weeks ago, someone asked me - who are the people in your life that inspired you and shaped your path? Then they said - you are that person now. The things you say, and how you act inspires others around you, and has an impact on the path they take.
One of our missions at Macadamian is to inspire young students to pursue a career in technology. We believe that if we don't get students excited about technology and design, we're going to have a serious shortage of designers, engineers and computer scientists in the next couple of decades, and we're going to lose our innovation edge. So, we're one of the founders of the Ottawa High School Technology Program, and we recently invited in 3 high school students to work with us for a semester, because we think we can make a dent, and help reverse the trend of dwindling engineering enrollment.
Sylvain and I were talking about what we'd like our students to work on, and we decided that it was important to us that what they work on not be grunt work, but be a project that has an impact for Macadamian, and be something challenging. We'll mentor them through it over the course of the semester, so that they come away with the experience of working in a software company - from there they can decide if this is the career they want to pursue. Someone gave me that opportunity when I was in high-school - to do real, impactful work when I was on a high-school co-op term, and that has stayed with me since.
So here's the takaway - for most of the people reading my blog, I'd bet you continue to seek out mentorship, but also have an opportunity to mentor others. Take a chance and invite in some high-school co-op students, give them the chance to do real work, give them guidance, and you might be surprised about what you learn and what kind of impact you can have.
Thursday, February 19, 2009
Mockups are the new spec
Last week I had the pleasure of chatting with Matt Miller and Jeff Perkins, co-founders of OfferTap, an exciting new company that is creating a platform that helps online merchants better target buyers and optimize e-commerce revenue.
I met Matt and Jeff several months ago at a conference on distributed development and global outsourcing. What struck me was that they had been very successful at creating their entire product with an outsourced team by never writing specs. They share our view at Macadamian - that a visual design is a far better spec than a written spec could ever be.
I caught up with Matt and Jeff to find out more about how they made it work with an outsourced team developing a new product in another country.
How did you come to the conclusion that a visual design was a better way to describe the product to your development team than a written spec?
Jeff: Actually, when we first started, we had put a lot of work into creating a spec and spelling out detailed business requirements. We found that despite that, we were spending a lot of time going back and forth to explain the requirements.
Matt: Our partner was impressed with the level of detail we had put together, but we spent a ton of time educating them about how the product would visually fit in with other e-commerce solutions, tie in with existing ads, and explaining overall how it would work.
Jeff: It came from the frustration of not getting to the end result fast enough. Every hour spent writing spec was an hour we were further away, and worse, it didn't seem to matter because it wasn't helping the development team. What our specs were missing was both the big picture and the user flow.
I understand you use hi-fidelity mockups, as opposed to wireframes. Tell me more about that and why you choose to put a lot of detail in your mockups.
Jeff: For us, a wireframe wasn't going to do, because we were also using the mockups to describe what we were doing to investors and customers. A wireframe wouldn't give us the same level of impact. Plus, the designs were going straight to the development team. When you have a design team, wireframes work fine, but in our case we were the designers, and it was just as easy for us to create more detailed designs.
What if you're not a designer by trade? How do you communicate ideas to your team if you don't have the skills to do hi-fi mockups?
Matt: There are a number of tools you can use to get your idea across. When we were experimenting and fleshing out ideas, we used tools like Snag-It to cut ideas from other products, and used PowerPoint to arrange them. The end result was good enough for experimenting on the placement of elements, and showing the flow of the product.
How much time do you think you saved in development by using mockups in place of specs?
Matt: It was significant. Once we started showing the team mockups, they understood exactly what we were doing. Especially in the beginning - it probably saved us a couple of months of spec writing and back-and-forth. At the front-end of the project, it even helped our outsourcing partner understand who they would put on the project.
Jeff: We probably cut the lifecycle in half. When you're outsourcing development, I don't think it's language barriers that are a problem, it's understanding what the product is supposed to do, and the vision for the product - especially when the product is new and breaking new ground.
Matt: Words can be interpreted so many different ways. The clarity was almost instantaneous when we switched to doing mockups. After a month of back and forth, they had a big AHA moment. It also let us switch from a Waterfall approach to Scrum, which we used for the remainder of the development.
What did you write down?
Jeff: We did write down a series of high-level business requirements, some background on the product strategy, and a list of features. That gave everyone the high-level view of what we were trying to accomplish.
Did working with an Agile process like Scrum not make it hard to get quotes from prospective outsourcing partners?
Jeff: A fixed-price contract doesn't guarantee that your partner will deliver what you want.
Matt: That's exactly what happened - we started down the path of describing everything, and we ended up spending so much time trying to cross the T's and dot the I's that we never got around to building it.
Jeff: The opportunity will pass you by working that way.
Matt: We actually found that doing a few mockups made it easier to find the right partner. We could tell by the questions they were asking, who they involved in the process, and how detailed their plan was whether they were grasping the product from the get-go.
How would you sum up what you learned for other product companies?
Matt: Build it first - get as close to building a prototype as you can. We built mockups to describe the features - that gives you a clear vision of what you're doing and helps you describe it to others. Don't spend time creating artifacts no-one will use.
Jeff: Adopt an agile methodology that lets you iterate fast, and solicit feedback early and often. A waterfall approach can lead you to analysis paralysis and keep you from innovating.
I met Matt and Jeff several months ago at a conference on distributed development and global outsourcing. What struck me was that they had been very successful at creating their entire product with an outsourced team by never writing specs. They share our view at Macadamian - that a visual design is a far better spec than a written spec could ever be.
I caught up with Matt and Jeff to find out more about how they made it work with an outsourced team developing a new product in another country.
How did you come to the conclusion that a visual design was a better way to describe the product to your development team than a written spec?
Jeff: Actually, when we first started, we had put a lot of work into creating a spec and spelling out detailed business requirements. We found that despite that, we were spending a lot of time going back and forth to explain the requirements.
Matt: Our partner was impressed with the level of detail we had put together, but we spent a ton of time educating them about how the product would visually fit in with other e-commerce solutions, tie in with existing ads, and explaining overall how it would work.
Jeff: It came from the frustration of not getting to the end result fast enough. Every hour spent writing spec was an hour we were further away, and worse, it didn't seem to matter because it wasn't helping the development team. What our specs were missing was both the big picture and the user flow.
I understand you use hi-fidelity mockups, as opposed to wireframes. Tell me more about that and why you choose to put a lot of detail in your mockups.
Jeff: For us, a wireframe wasn't going to do, because we were also using the mockups to describe what we were doing to investors and customers. A wireframe wouldn't give us the same level of impact. Plus, the designs were going straight to the development team. When you have a design team, wireframes work fine, but in our case we were the designers, and it was just as easy for us to create more detailed designs.
What if you're not a designer by trade? How do you communicate ideas to your team if you don't have the skills to do hi-fi mockups?
Matt: There are a number of tools you can use to get your idea across. When we were experimenting and fleshing out ideas, we used tools like Snag-It to cut ideas from other products, and used PowerPoint to arrange them. The end result was good enough for experimenting on the placement of elements, and showing the flow of the product.
How much time do you think you saved in development by using mockups in place of specs?
Matt: It was significant. Once we started showing the team mockups, they understood exactly what we were doing. Especially in the beginning - it probably saved us a couple of months of spec writing and back-and-forth. At the front-end of the project, it even helped our outsourcing partner understand who they would put on the project.
Jeff: We probably cut the lifecycle in half. When you're outsourcing development, I don't think it's language barriers that are a problem, it's understanding what the product is supposed to do, and the vision for the product - especially when the product is new and breaking new ground.
Matt: Words can be interpreted so many different ways. The clarity was almost instantaneous when we switched to doing mockups. After a month of back and forth, they had a big AHA moment. It also let us switch from a Waterfall approach to Scrum, which we used for the remainder of the development.
What did you write down?
Jeff: We did write down a series of high-level business requirements, some background on the product strategy, and a list of features. That gave everyone the high-level view of what we were trying to accomplish.
Did working with an Agile process like Scrum not make it hard to get quotes from prospective outsourcing partners?
Jeff: A fixed-price contract doesn't guarantee that your partner will deliver what you want.
Matt: That's exactly what happened - we started down the path of describing everything, and we ended up spending so much time trying to cross the T's and dot the I's that we never got around to building it.
Jeff: The opportunity will pass you by working that way.
Matt: We actually found that doing a few mockups made it easier to find the right partner. We could tell by the questions they were asking, who they involved in the process, and how detailed their plan was whether they were grasping the product from the get-go.
How would you sum up what you learned for other product companies?
Matt: Build it first - get as close to building a prototype as you can. We built mockups to describe the features - that gives you a clear vision of what you're doing and helps you describe it to others. Don't spend time creating artifacts no-one will use.
Jeff: Adopt an agile methodology that lets you iterate fast, and solicit feedback early and often. A waterfall approach can lead you to analysis paralysis and keep you from innovating.
Tuesday, February 3, 2009
Incremental innovation in 2009
I've been thinking a lot about what we can expect in 2009 in new product innovations. Chances are we'll see mostly incremental innovation and very few breakthrough innovations, at least from established product companies.
People, and companies, are risk averse in a down economy. Few are ready to place a big bet on a product they aren't sure is going to generate immediate revenue. Incremental innovations, like small product improvements, should yield incremental revenue from existing customers. Apple, the company most people look to as one of the world's best innovators, released a series of incremental innovations this year at MacWorld - no breakthroughs for the Mac faithful this year.
Despite a lack of disruptive innovation, I'm hopeful that 2009 is a breakthrough year for design-thinking, driven by product companies wanting to reduce the risk of creating the wrong product or wrong innovation. I'm predicting that more product teams will invest in user research and prototyping, so that they can be more sure that they are focusing on creating the products and features that will provide the most value to their customers, and hence provide the biggest return.
People, and companies, are risk averse in a down economy. Few are ready to place a big bet on a product they aren't sure is going to generate immediate revenue. Incremental innovations, like small product improvements, should yield incremental revenue from existing customers. Apple, the company most people look to as one of the world's best innovators, released a series of incremental innovations this year at MacWorld - no breakthroughs for the Mac faithful this year.
Despite a lack of disruptive innovation, I'm hopeful that 2009 is a breakthrough year for design-thinking, driven by product companies wanting to reduce the risk of creating the wrong product or wrong innovation. I'm predicting that more product teams will invest in user research and prototyping, so that they can be more sure that they are focusing on creating the products and features that will provide the most value to their customers, and hence provide the biggest return.
Friday, January 30, 2009
Why Design-Thinking hasn't caught on in software
One of my colleagues, Francis Beaudet, just wrote a great article for our Critical Path newsletter called Why is Design Thinking Failing to Penetrate Software Companies? I love his point about how software teams think "Waterfall" when they hear "design up front" and run away screaming.
I'll add another reason why UX and usability isn't catching on at all software companies (or why some are simply paying it lip service) - with most enterprise software, the Buyer is not the User. Large enterprise systems are sold at a C-level or to the IT department, and often the people that have to actually use it, and whose productivity is supposed to go up tenfold for using it, aren't consulted.
On the other hand, in e-commerce, and to some degree SaaS, usability and user experience design is taken very seriously, because even small improvements in usability result in more conversions and more purchases. Salesforce.com is a good example - compared to traditional monolithic CRM systems, Salesforce.com is infinitely more usable. Why? Because it's sales-people who are buying it, not IT, and if Salesforce.com was difficult to use, they wouldn't buy it.
I once visited a large enterprise software company, and they asked me - how do you work? When I explained how we approach a project - observing users, rapid prototyping, testing and validating with users, and so on, their reply was, "that's nice, but we don't have that luxury here. We just hire good designers and make our best guesses".
Enterprise software companies could take a few lessons from .coms and SaaS companies, before their lunch is completely eaten.
I'll add another reason why UX and usability isn't catching on at all software companies (or why some are simply paying it lip service) - with most enterprise software, the Buyer is not the User. Large enterprise systems are sold at a C-level or to the IT department, and often the people that have to actually use it, and whose productivity is supposed to go up tenfold for using it, aren't consulted.
On the other hand, in e-commerce, and to some degree SaaS, usability and user experience design is taken very seriously, because even small improvements in usability result in more conversions and more purchases. Salesforce.com is a good example - compared to traditional monolithic CRM systems, Salesforce.com is infinitely more usable. Why? Because it's sales-people who are buying it, not IT, and if Salesforce.com was difficult to use, they wouldn't buy it.
I once visited a large enterprise software company, and they asked me - how do you work? When I explained how we approach a project - observing users, rapid prototyping, testing and validating with users, and so on, their reply was, "that's nice, but we don't have that luxury here. We just hire good designers and make our best guesses".
Enterprise software companies could take a few lessons from .coms and SaaS companies, before their lunch is completely eaten.
Subscribe to:
Posts (Atom)
