This is a post that is the 1st in what I hope to have be a weekly series. It's goal is to help you learn something new every week. I need some more contributors to help keep this running so if you would like yo help out please PM me. This post was put together by /@svetkaelisy. A big thank you to them for taking the time.
I'm planning to write a book informing non-technical people on how to deal with technical projects in order to make them a success, because there are certain secrets that are known to software practitioners in the industry but not to most other people. In fact, currently building software is not as common in the public knowledge as construction and working on a car, but I'm hoping to change that.
The biggest secret to building computer software occurs long before a software engineer touches the keyboard for the first time, the project manager charts a path to success or the executive authorizes a budget. This applies to both customer software solutions and software products. It begins when working with the customer. This is what typically happens in a software solution scenario:
Customer: I want A, B, C and D. Vendor/Engineer/Salesperson: Done!
The engineer/vendor goes out and starts building the app/product/solution. They come back with the first milestone.
Customer: Actually, we changed our mind, we'd like B, C and D and some E. Remove E. V/E/S: Well, we can't remove all of A since we already started, but we'll add E. In fact, it'll be the next thing on our list.
The engineering team goes back to their computers and bangs out some work. Milestone 2 rolls around, the last before the deadline.
Customer: Now that we look at it, it's clear to any fool that what need to be in is A, C and D. Let's forget about E and since Mary from accounting and audits called, we need to add F, G, H, I, J, K, L, M, N, O, P to comply with internal policies. But that's small, so you can totally handle that. Engineering: I stab you now.
The engineering team goes back to their computers. The codebase is a mess, the quality from so many changes is low, there are tons of bugs that the customer is complaining about. The situation can be completely the same if you're developing an app like Snapchat and have a focus group of trial customers.
Over time, engineers have developed little hack like the Agile methodology which prescribes that changes are enormous and expected, you should simply accept that fact. The non-technical solution to this is to become a "visionary" and be a giant unyielding asshole to everyone who disagrees, whether they are right or not. Project managers just accept fate and budget in 100% more time than the estimates given by engineering.
I don't do Agile anymore. I also listen to people and accurately estimate the effort needed. There is something that experienced salespeople have taught me over time that I will call "the impute" by stealing Steve Jobs' term from Walter Isaacson's biography.
The impute works like this. In the beginning, the customer exists in 2015, with all the fires and distractions of their job (or life, if you're building a consumer app). The answers they will give you are going to be the same as when you asked people about the iPhone in 2006. In 2006 nobody knew about what a giant impact a full-screen smartphone with full computing capabilities was going to have and what the app stores were going to do to the market of smartphones as a part of our daily life. In 2006 if I asked a customer what they wanted in a smartphone, the answer would be "a Blackberry!"
I need the customer to exist in 2017. At this point problems that are currently overwhelming and annoying have been dealt with, we live in a new reality of existing tools to deal with problems and the customer and we want feedback on those tools. To put it succinctly, by 2009 customers could tell you what they wanted from IPhone 4 and what apps they wanted on their phone. Collecting that feedback and transforming it into a design for your product leads to a software construction process that's much smoother since the customer is not learning anything new while each milestone is being presented, they are just checking to see if their expectations are being conformed to. The changes encountered by the engineering team will be minor.
That's the entire secret, put them 2 years ahead in time and then listen to what they have to say about what they want. Don't keep going back and forth with feedback because learning how to build a skyscraper by building skyscrapers is very expensive. It's much cheaper to do some blueprinting work first. Most projects executions discover the ideal product to be built at the end of actually building the product.
The how of doing an impute can get detailed. Everyone does proof-of-concept projects, but they typically only address the technical risks and do not deal with the mindset risks of un-imputed customers. There are several proven tools that the point person for a product can use to impute the mind of the customer with the a vision of the future:
Most teams that I have seen will imagine and design a solution, but not fully work through it. 4. Finally, once I spend a week with my customers poking and prodding the mockups, I like to spend working backwards. At this point in time you want the components in the consensus solutions(s) and create a value stream map, to specifically map out and explicitly talk about what you're giving to the customers.
After going through this process and spending working through the problem, solutions and identifying value-adds, it's exceedingly rare to have last-minute changes or any changes at all. The impute requires discipline in involving domain experts and typical customers as part of its process, because the problem that it solves is human, not technical. By forcing your customer's to work through potential solutions to the problem and learning more about the problem removes thinking inertia and positions them to think more from the viewpoint of having solved the problem instead of just facing it.
Cheers and I hope that this will be useful.
I'm planning to write a book informing non-technical people on how to deal with technical projects in order to make them a success, because there are certain secrets that are known to software practitioners in the industry but not to most other people. In fact, currently building software is not as common in the public knowledge as construction and working on a car, but I'm hoping to change that.
The biggest secret to building computer software occurs long before a software engineer touches the keyboard for the first time, the project manager charts a path to success or the executive authorizes a budget. This applies to both customer software solutions and software products. It begins when working with the customer. This is what typically happens in a software solution scenario:
Customer: I want A, B, C and D. Vendor/Engineer/Salesperson: Done!
The engineer/vendor goes out and starts building the app/product/solution. They come back with the first milestone.
Customer: Actually, we changed our mind, we'd like B, C and D and some E. Remove E. V/E/S: Well, we can't remove all of A since we already started, but we'll add E. In fact, it'll be the next thing on our list.
The engineering team goes back to their computers and bangs out some work. Milestone 2 rolls around, the last before the deadline.
Customer: Now that we look at it, it's clear to any fool that what need to be in is A, C and D. Let's forget about E and since Mary from accounting and audits called, we need to add F, G, H, I, J, K, L, M, N, O, P to comply with internal policies. But that's small, so you can totally handle that. Engineering: I stab you now.
The engineering team goes back to their computers. The codebase is a mess, the quality from so many changes is low, there are tons of bugs that the customer is complaining about. The situation can be completely the same if you're developing an app like Snapchat and have a focus group of trial customers.
Over time, engineers have developed little hack like the Agile methodology which prescribes that changes are enormous and expected, you should simply accept that fact. The non-technical solution to this is to become a "visionary" and be a giant unyielding asshole to everyone who disagrees, whether they are right or not. Project managers just accept fate and budget in 100% more time than the estimates given by engineering.
I don't do Agile anymore. I also listen to people and accurately estimate the effort needed. There is something that experienced salespeople have taught me over time that I will call "the impute" by stealing Steve Jobs' term from Walter Isaacson's biography.
The impute works like this. In the beginning, the customer exists in 2015, with all the fires and distractions of their job (or life, if you're building a consumer app). The answers they will give you are going to be the same as when you asked people about the iPhone in 2006. In 2006 nobody knew about what a giant impact a full-screen smartphone with full computing capabilities was going to have and what the app stores were going to do to the market of smartphones as a part of our daily life. In 2006 if I asked a customer what they wanted in a smartphone, the answer would be "a Blackberry!"
I need the customer to exist in 2017. At this point problems that are currently overwhelming and annoying have been dealt with, we live in a new reality of existing tools to deal with problems and the customer and we want feedback on those tools. To put it succinctly, by 2009 customers could tell you what they wanted from IPhone 4 and what apps they wanted on their phone. Collecting that feedback and transforming it into a design for your product leads to a software construction process that's much smoother since the customer is not learning anything new while each milestone is being presented, they are just checking to see if their expectations are being conformed to. The changes encountered by the engineering team will be minor.
That's the entire secret, put them 2 years ahead in time and then listen to what they have to say about what they want. Don't keep going back and forth with feedback because learning how to build a skyscraper by building skyscrapers is very expensive. It's much cheaper to do some blueprinting work first. Most projects executions discover the ideal product to be built at the end of actually building the product.
The how of doing an impute can get detailed. Everyone does proof-of-concept projects, but they typically only address the technical risks and do not deal with the mindset risks of un-imputed customers. There are several proven tools that the point person for a product can use to impute the mind of the customer with the a vision of the future:
- First, realize that you're getting them to think from a certain viewpoint, not about a particular specific solution to a problem. You're not selling your vision of the product, you want them to experience a journey and then reason as a worldly seasoned traveler. You will do them no good by getting them hung up on a specific approach, because they will fight you if a better direction for the product is discovered.
- Sketching and envisioning is the right first step. Your customers are going to throw out some ideas to you for what they want. You will have some ideas about what they want. All of these are going to suffer from the inertia of thinking, living in 2015. Get them out of the way and out of mind. As a result of this exercise, there may be a unified consensus of what should be built. In a typical design process this would mark the start of preparations for approval of the project and its construction. That is a terrible idea.For bonus points, have 5-6 different consensus solutions. It helps to have a strong critical thinker who can see the problem from multiple lenses (different types of customer use cases or customer mentalities).
- Where the rubber meets the road is to work through the consensus solution. You want to give them hands-on dummy mockups of what the solutions are going to look like and solve real-world problems. It's amazing how different things are once a customer/user has the future product in their hand. We could mock up the GrubHub mobile app by printing out the different screenshots, cut them out to size of an iPhone screen and give them to people to poke with their finger. This is where the majority of the working-through knowledge will be discovered and move your customers ahead in time. 99% of engineering and design teams don't go through a hands-on approach over a period of time. It's important to realize that ideas don't come on demand and it may take some time before some really good feedback is provided.
Most teams that I have seen will imagine and design a solution, but not fully work through it. 4. Finally, once I spend a week with my customers poking and prodding the mockups, I like to spend working backwards. At this point in time you want the components in the consensus solutions(s) and create a value stream map, to specifically map out and explicitly talk about what you're giving to the customers.
After going through this process and spending working through the problem, solutions and identifying value-adds, it's exceedingly rare to have last-minute changes or any changes at all. The impute requires discipline in involving domain experts and typical customers as part of its process, because the problem that it solves is human, not technical. By forcing your customer's to work through potential solutions to the problem and learning more about the problem removes thinking inertia and positions them to think more from the viewpoint of having solved the problem instead of just facing it.
Cheers and I hope that this will be useful.