Seeding a Product Org
Despite the ever-growing body of literature around the subject, product management is still a relatively new field. Much of the innovation happens 'in the field,' and meta-lists of reference material frequently link to articles and blog posts instead of textbooks.
This can be equal parts exciting and intimidating. It's exciting because we're essentially watching a role take shape (and maybe influencing it too.) It's intimidating because, shit, what's next?
While there's plenty of material around the kind of qualities one needs to be successful in a product company, there isn't enough talk about what is arguably the most important phase of any product org: setting it up.
Remember, a product manager's responsibilities can vary widely across different companies, depending on what the team needs. Figuring out those needs and seeding a product org involves some of the most crucial decisions a team will ever make.
But what does that mean, really?
Everything Sets a Precedent
Part of this is obvious. We've never had a product team at Fyle before. Thus, we are aware that some of the everyday decisions that we make today can impact the entire team in the years to come.
For example, we're ironing out our new product development pipeline even as I write this article. I know for a fact that the very names we choose for different stages of the pipeline need to be rock solid, the result of much thoughtful discussion. This is because you can be certain those names are going to stick. They're also going to affect all of our communications going forward. They'll show up in the roadmaps we'll be writing years from now, so do you want to call it 'Product Research' or just 'Research'? Be sure.
The less obvious aspect of this is in the precedents we're setting in our every action. This is something we expect and can prepare for to make things easier in the future. Early last year, Fyle's various teams (pods created to work on a single project) took it upon themselves to reach out to our customers by themselves for research and problem validation.
For many of us, this was the first time we were drafting user-facing emails and other communication. It was also the first time we were putting together scripts to set the interviewee at ease and coax out relevant information.
Additionally, because we were all figuring this out together, we made it a point to share our learnings to ensure we were all on the same plane. We also worked towards building a common communications library that we can reuse every time the need arises.
In doing so, every member of the Fyle product org is currently involved in the decision of exactly how user-focused we are and how we intend to maintain that level.
Communication is Key
It follows from the previous point that, given the weight that comes attached to every decision we need to make, we're all expected to be able to do an excellent job communicating these decisions (and the reasoning behind them) to each other.
Clarity in communication is probably the most important qualification you can have when joining a team like this.
Fyle's customers range from:
1. Regular employees, who want nothing more than to stop having to think about expenses, and
2. CFOs and finance admins who have deep insight into specific domain knowledge and very high expectations from an expense management software.
Fyle's product team needs to be able to empathize with both of these groups, effectively consumers and businesses, with equal ease, and share their learnings with the wider org.
This one you probably expected. In a nascent team of any sort, roles and responsibilities frequently shift wildly, and titles have very little bearing on the work one might eventually expect to do.
Fyle is a young team, and the bare minimum we expect from new members is that they can function perfectly without constant supervision. Our ideal candidates are people who thus show a high level of agency, who start their week by setting their own targets for bringing their teams closer to success.
The downside to this kind of environment is that while high agency individuals may easily navigate the org, others may find vital components of a typical product team missing. For example, we're still figuring out what the 'product track' in our org will look like and what levels of proficiency we ought to expect at various stages. But, what we do know is that these decisions need to result from discussions within the product org itself, as it charts its own future.
Tech That Works
A popular trope from product management literature is 'dealing' with tech and 'handling' the stakeholders. "What should I do when I receive an effort estimate from engineering that I know is inaccurate?"
In reality, though, these are problems faced by larger, more established orgs. Nascent product teams don't need to think too hard about optimizing engineering, as they're likely already working at an impressive level of efficiency.
This is one of my favorite things about working at Fyle at the moment. We are not looking for project managers right now. The 'build' step of our research-build-release pipeline is still in pretty good shape, and that's not where we need help. Our research and release phases could be a lot better, and that's where we need you to focus.
Solutioning is a Shared Responsibility
A side effect of working with a tech team that shows a high degree of agency is that product owners are not, and will never be expected to be, 'idea factories.'
Product folks are the final owners of the products, but their most significant contribution to product development is still research and direction. The onus of finally coming up with a solution to a customer's problems can lie in many places, with Design, Product, or Engineering.
When it lies solely with Product, problem-solving is commonly cited as some of the most exciting work a PM gets to do. I've often heard it described as "building without code."
At Fyle, solutioning is a shared responsibility, and PMs are only one part of solving that puzzle.
Fyle is looking to grow its product team, and we're looking for someone who can perform well in the environment described above.
Specifically, we're looking for someone to own our entire library of integrations. Fyle envisions a world where not a single second is spent on expense management. A huge part of achieving this is making it possible to explore and use the information created by Fyle outside the confines of an expense management system and inside other systems.
That's where our integrations come in. The solution space is vast, and so is the range of user journeys we will need to understand and build for. We could use some help.
If you think you might be a good fit for us, please get in touch. There's a more concise listing for the role here. If you're looking to share it, I will encourage you to share this article instead.
In addition to the qualities I've already described, there are a couple of soft preferences I'd like to call out separately:
Fyle has had a great track record with hiring freshers and mentoring them into their roles. About 70% of our engineering team joined as interns or freshers, and it's worked out wonderfully for us. We believe we can make this work for product roles as well, which is why our experience requirement for this role is set to 0. If you're looking to break into the world of product management, we want to let you know you're welcome to apply here.
Our current product team is a bunch of cis het dudes. However, the products that we are building are intended for use by everyone, and we'd love for our team to reflect that kind of diversity. If you belong to any typically underrepresented community, let us take this chance to actively encourage you to apply.