- Published on
Deep dive on my time at BetterTexter
- Authors
Background
Better Texter is an iMessage Application that utilizes Artificial Intelligence to help people communicate more effectively via text. It's designed for anyone who wants to elevate their texting game, from early career professionals to ESL (English as second language) speakers, and offers a seamless, user-friendly experience.
The work I did here wouldn't have been possible without Miles he is a sales oriented entrepreneur who wanted to take a chance on Software Engineer like myself to lead the product. Also, the team was very small and the developer time we had access to was part time, this meant that although I was the "Technical Product Manager" for BetterTexter I had to be incredibly versatile and wear all the hats 🤠
Tech Stack:
- Swift
- UIKit
- OpenAI
- Firebase
Key learning points
Developer time is sacred
This point will resonate with any founder or builder who is non-technical, but coming from a technical background you don't really realize how important it is especially when time-constrained. Its vital that you structure tasks to require as little grand vision ambiguity as possible; this way the developer can focus solely on the technical implementation of the task.
Defining realistic vision
When we first started our workflow was less than ideal. We would have multiple brainstorming sessions where we would be incredibly imaginative about the feature set that we "should" have. All this early thinking was great for morale and defining direction but I wish we also gave more credence to actually validating the features before building upon them for our vision(especially since we did take a hit on morale when the dust settled) This was incredibly stark and apparent when ideated multiple really powerful features like:
- A digital messaging clone, a way to train/RAG ontop of all the messages you've sent to have the AI respond/message people the way you would.
- Auto send replies but with an AI Integration
While this really got us excited we only were able to see the pitfalls when we wanted to build the features for the platform we really wanted -- Apple. While there were potential workarounds through leveraging the underlying key value db that is exposed through iMessage on Mac link. It just didn't seem like we were going to be able to do that without compromising seamless-ness of the onboarding experience and the breaking the App Store rules.
Create flexible day to day direction
Before this experience, I always primarily played the role of a software developer. This meant I was given task that was already scoped out at varying degrees of intricacy but largely the biggest difficulty was creating technical implementations and figuring out what the best way of executing that was.
Coming to the table with multiple options is the most efficient way of getting things done, since it creates a sense of autonomy for the developers and allows them to feel greater ownership on the task on the task they choose. This enables better development. I understood that being a manager for a small team requires more detail for how a task is going to contribute to the greater vision. So the chosen tasks are always inline with the grander vision of the product itself. (Side note: I mention vision in a technical and non technical capacity here)
Investing in analytics
One thing I wish I pushed harder for during our initial beta release was incorporating a proper analytics platform from the get-go. This would have given us the clarity to see how our early users are truly using the product rather than relying on 1:1 user interviews which brought in bias and wasted time. We ended up using Microsoft Clarity but it was still an afterthought and just gave us a heatmap at the time.
No deadtime for background tasks
A pretty powerful framework I quickly realized was making sure I always had visibility regarding the nature of the tasks that needed to be done. Certain tasks involve parameter outside our reach and thus need to be given additional time to ensure we hit our internal deadlines. We termed these type of tasks as "background" as it was always in the process of some task that could be done in the background. It is valuable and absolutely necessary when working in a time constrained environment. To really drill down what I mean let me point to a time when we were preparing for our beta launch, we faced significant challenges with Apple's strict App Store rules. We had to make sure our AI features followed privacy rules and met the necessary performance standards for approval. We carefully prepared our submission and tackled potential issues in advance to make the app review process smoother. This careful planning was crucial to avoid downtime and ensure that we could add new features smoothly without disrupting the user experience.