Expona
Context-trained AI agent delivering noise-free, cost-efficient conversational intelligence
How do we seek truth and integrity in the process of building a product? It’s a curious question and perhaps not one we automatically think about. Regardless, it has been one I’ve been mulling since I began practicing product strategy here at Philosophie (Now InfoBeans).
I start each day reminding myself that I know nothing. My understanding is often limited, hampered by a myriad of cognitive biases, as well as my own inherent flaws as a human being. In light of that I operate on the job in the spirit of collaboration, trying to figure out the best ways to be productive and useful to the developers and designers who I jam with.
Meanwhile, how are we as a company embracing this concept of a truthful product? It is perhaps testament to the thinking put into the work here that our mantra is make it better.
What is making it better if not about being open and prepared to:
While certainly not definitive, the work we have accomplished to date at Philosophie certainly suggests that practicing the above makes for the most truthful product. We see that as being when minimum usable product meets the human problem we are trying to solve for.
What follows is an attempt to articulate some of the emergent learnings I have uncovered during my first twelve weeks here. I’ve spent a good portion of my time working with our enterprise clients thus a lot of the thinking contained in here relates to said experiences. They are certainly not things I practice with fluency yet. I myself am an iterative process in motion.
The organizational matrix of an enterprise company is a living, breathing, and complex system. It is easy to forget that it is made up of human beings. Human beings who are trying to both fulfill the needs of the system and their own personal goals.
More often than not there are a myriad of stakeholders, all invested in having different aspects of the product prioritized and they don’t always see eye to eye. It can be tricky to navigate this and strive to build a robust product that is hyper-focused on the user.
In such a situation, it is easy to fall back on process as a panacea. Just remember, process cannot trump people. Process cannot be wielded as a weapon against what we might deem as the inefficiencies of large organizations. There are no winners when we pit our process against their embedded ways of working. Channel your inner Yoda. Avoid being this person:
Providing our engineers and designers enough context of the inner workings of how the business, marketing and tech have to align in a large organization is vital to their work. This not only makes for better product development, it also helps bolster the consulting expertise of the wider team. We believe that all our Philosophers should be equal in their ability to empathize with a product owner be it entrepreneur or C-Suite.
We want our clients to be good at what they do. Manifesting that has never been through telling them how to do it. We show them through the work. This is to imbue them with the capability to continue building an ever better product when we step off the project.
But that’s not always an easy thing to do. Work is hard and change can be painful. Very often, when a product is being originated out of a large organization, the folks working on the project are typically:
As product consultants we’re just amped to be building something new and can be blinded by this. We assume it’s fun for everyone but for the stakeholders involved, this is a pain in the ass and goddamn hard. So be kind. Err on the side of empathy always. It’s hard. I’m still guilty of the occasional curt email.
Experiment with the ways in which we introduce the process. Make it fun. Gamify it even. Never make it adversarial. Let them come round to it and in the meantime, just allow the work to be the vehicle for the process, not the other way around.
This is your common language. I say this because the one thing that binds the product is the code that manifests it. Code has no opinion, it has no shades of grey. It can be nothing but truthful.
Nobody expects me to deliver production code like my engineering brethren. However, being a product strategist with a working comprehension of programming makes for one who asks better questions and makes better choices for the product.
Making the effort to gain a surface understanding demonstrates commitment to our craft. I do it because I want to improve the quality of my work product. Growth in this role means becoming a teammate who is more holistic and armed with a deeper understanding of the work a balanced team is tasked with doing for a product owner.
“If someone is able to show me that what I think or do is not right, I will happily change…”
That is the crux of it I think. When I couple Aurelius’ words and what I have observed so far, my gut tells me that what us product peeps should aim for is:
My goal in the coming months is to embody these pillars as best as I humanly can. In doing so I hope to steer my team and clients to that truthful product they all work so hard at creating.