Cindy F. Solomon of SUPA Product Academy chats with Malcolm Knapp of the Engineer Accelerator to apply the process that Malcolm teaches for creating the vision for a product prior to building it. The “lean definition process” is a product definition discovery process that Malcolm has developed and implemented over many years of building hardware products and uses to arrive at a cross team concensus of the product definition prior to building.
Listeners are invited to join the discussion, ask questions and provide your own perspectives and approaches for what process and tools you currently employ to arrive at a cross functional and validated vision of the product prior to build.
About Malcolm Knapp
I help small companies and individual people with defining the product they are trying to make and implementation of the electronics component of that product. In all, I have over ten years of project experience ever since I designed and built a low cost rechargeable lantern from The Millennium Villages project in 2004.
My education includes a combined BA in Science, Engineering, and Society from Pitzer College, a BS in Electrical Engineer from Columbia University and a MS in Electrical Engineering from Columbia. I chose this type of degree because politics, economics, and culture, effect what is built just as much as what is technically possible and I wanted to understand how.
This is the first in a series of conversations highlighting the issues involved in talking about this process, developing it as a product management tool, and solving the complexity of visualizing the product definition before development begins.
Malcolm Knapp of the Engineer Accelerator and Cindy F. Solomon of SUPA Product Academy delve into systems thinking and cross-functional collaboration to create the Lean Spec document to uncover what is known and unknown about the product before undertaking development.
In this 3rd episode, we discuss where in the product lifecycle process the lean spec is created, and who is responsible for driving it forward to execution. Distinctions regarding project management, product management, product marketing management, UX, CX and QA focus are uncovered.
In this 4th discussion of the series, they use a mobile application product idea to work through the probing questions necessary to identify what is known and what is unknown to flesh out the product concretely.
In this 5th discussion of the series, Malcolm further zooms in on the block diagram and accordion text outline of features, behaviors, connections and granular details that define the product to be built.
Cindy and Malcolm discuss applications of the lean spec to the product development process
In this 7th discussion of the series, Cindy and Malcolm discuss the importance of appropriate internal naming of features based on functionality, the challenges of arriving at agreed nomenclature, and the value of the Lean Spec to draw out identification of the names.
In this 8th discussion of the series, Cindy and Malcolm discuss what pre-requisites might be necessary for attendees to the Lean Spec training, tools and software, as well as value of implementing the Lean Spec within both hardware and software product organizations.
In this 9th discussion of the series, the first in 2017, Cindy and Malcolm discuss what cohorts will learn in the Lean Spec training, consider how to map over domain expertise from across different functions and how is this relevant to other domains and product types. We talked about the product’s characteristics, but not how the features relate which is represented in the block diagram.
Discussing specificity – how specific you need to be at that moment in the product process. Many people speak about the product in a vague way and there is a necessary level of specificity required to determine actionable items. There’s a skill to knowing how far/deep to go at this moment in the process – it is a challenge to not jump to (for engineers) coding or identifying materials – we don’t want to spend time designing what we already know before we uncover what we don’t know – the Lean Spec guarantees integration with other parts of the process aligning across functions. System thinking, the proper hierarchical organization of knowledge of what is known about the product (product experience is the gestalt of the hardware, software and the design – part of what you’re trying to do is talk about “experience” but not only the end-user perspective, but the objective creation of the product).
Anca Mosoui joins the discussion to determine how to implement the Lean Spec in web and tech development. Translating intent into code. What are the things that you cannot emperically test? What level view is the “Lean Spec”? It’s a phase in the process – high level information is different in both situations.
Anca Mosoui returns to the discussion to determine how to implement the Lean Spec in web and tech development. Identifying the discovery space, the necessary knowledge, Agile process and perspective from varying teams.
Previously, we’ve talked about the heirarchical list of information: product level, device level, feature level which just captures one aspect of the fixed things in the product (that don’t change with time). Its an incomplete picture – so then we have to take each feature/functionality “name” and treat it as a systems and signals block. Then determine how they’re related to each other and what flows between each block – how the information flows from internal, to external, and displaying how that works. In this episode, Cindy and Malcolm discuss systems thinking as applied to product development.
Sean Sill, calls himself an electronics systems consultant. He’s been doing product design & development for electronic hardware systems over 3 years. Has a background in theater, radio and theater production. He’s also done web apps and IOT. Sean’s office is in the Port Workspaces at Kaiser and is part of the Techliminal community. Sean joins Malcolm and Cindy to further discuss the thinking around the lean spec product definition.
Malcolm and Cindy to further discuss the thinking around the lean spec product definition.
Our guest today is David Ordall, CEO of Everbooked, a demand-based pricing startup, and ExaVault, a business file sharing startup. Previously, he has worked as VP of Engineering at Huddler.com and as CEO/CTO at CyberSense. David’s passion and area of expertise – is building technology companies. He is well versed in both the technical and managerial aspects of fast-paced, agile software development and the lean startup methodology.
Cindy and Malcolm discuss state machines and sequences – capturing what a product does vs. what a product is. This is one of the things that a lot of people ether don’t think about or think about in a vague way. What the product does impacts what it needs to be – this is yet another aspect of the product. We talked about the flow diagram, the heirarchical list of what it is – so now this is how you separate what it does from what it is – which requires skill. The experience of the product is everything together – it is very useful to be able to think about aspects of the product as distinctions – you use all of the noun pieces/features in the product and what it does is the verb. You constrain your vocabulary by what “is” the product. We get into the semantics of “product” and product concepts to be precise about the product description, especially at the beginning. Eventually the code is a very specific sequence of events
– if you wrote it in psudo code first, you could spend less time coding
– you can enumerate the behaviors of things and someone has to do it – therefore its the product manager’s domain
Cindy and Malcolm discuss
1. sequences are basically pseudo code – the power of writing code without syntax is a real skill provides ability to describe behaviors of things you want to have happen in a precise way
2. interfaces & why are they on the list? the reason is its a classic point where design conflicts arise – as a high level object you can view it all as one piece
3. the skills for translating/abstracting reality into forms that you can make. Everything we talked about are to simplify what you see in front of you into implementable actions – putting all the information that we’ve captured organized in such a way that it is transmittable
Cindy and Malcolm discuss scoping the product
1. how to extend the lean definition process
2. project scoping/implementation
3. revision process: how to deal with updates/changes lower on the development &/or new info
Cindy and Malcolm discuss extending the lean definition into implementation – into the build itself – the development phase of the product lifecycle. Taking the list of features and mapping the functionality over into the actual technology so that everything the product does and is must be aligned to reality of how it will be built. It provides the full list of things that must be done to determine how far you are in the process of identifying all the behaviors, features and functions including the boring stuff!
Cindy and Malcolm are joined by Barbara Tien, Co-Founder & CEO, Ponga. A Stanford graduate, Barbara had an early academic focus in cross-cultural communications prior to her career in technology as a product manager. Barbara has deep expertise in both hardware and software product management at the enterprise level, as well as with startups. She serves on the Membership Committee of the Founders Network peer mentorship program for tech startup founders. Ponga is building a software service to give design pros a way to collaborate with their clients by pointing into pictures. You can find more at pro.ponga.com
Hubert Palan, Founder & CEO, ProductBoard.com joins the discussion with Cindy F. Solomon and Malcolm Knapp to provide feedback on the validity of the Lean Definition Process. Hubert has over 15+ years of experience, MSc. in Computer Science, Berkeley MBA.
We walk Hubert through a Lean Definition inquiry of what the product is and how to communicate what the product is to be built. We grapple with developing the hierarchy of knowledge about the product features, characteristics, behaviors as well as how to sync internal mental models of what the product is, communicate across the organization to uncovering unknowns. How the Lean Definition process syncs with the process of identifying what the user needs and customer wants are.
The software application Productboard is a system of record for product management that helps teams make products people want: • Understand what users need • Prioritize what to build • Earn buy-in from colleagues & customers. With one system for helping manage everything product leaders care about, PMs are equipped to make better product decisions. https://www.productboard.com/