Podio Solutions Podcast

S1E1 - Open Discussion 1: “Podio as a Product Platform”

January 25, 2019 Brick Bridge Consulting Season 1 Episode 1
Podio Solutions Podcast
S1E1 - Open Discussion 1: “Podio as a Product Platform”
Chapters
Podio Solutions Podcast
S1E1 - Open Discussion 1: “Podio as a Product Platform”
Jan 25, 2019 Season 1 Episode 1
Brick Bridge Consulting

Season 1 – Episode 1 – Open Discussion: “Podio as a Product Platform”

Discussion Outline:

  1. Introduction and Topic: Is Podio positioned to deliver for wide-scale solutions?
  2. 1st Discussion: Podio Solution Styles - One-off, Mass-Customize or full Products? Or all of the above?
  3. 2nd Discussion: People - Who are the clients for the above solution styles? Are they development agencies or enterprises
  4. Real Talk: Current Gaps – What could be missing from Podio (and maybe Globiflow) to make it more “Product Platform” or “Mass Customize” oriented?
  5. Deep Dive: Podio’s API “readiness” for integrations and toolsets to enable more “Product Platform” or “Mass Customize” orientation.
  6. Audience Engagement: Solving Podio Gaps – Podio Developers and Power users – Submit your gap!
  7. Up Next: mPact Pro - How we built a full Podio-based product for a client from concept to revenue.


Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.

Support the show (http://www.brickbridgeconsulting.com/podcast)

Show Notes Transcript

Season 1 – Episode 1 – Open Discussion: “Podio as a Product Platform”

Discussion Outline:

  1. Introduction and Topic: Is Podio positioned to deliver for wide-scale solutions?
  2. 1st Discussion: Podio Solution Styles - One-off, Mass-Customize or full Products? Or all of the above?
  3. 2nd Discussion: People - Who are the clients for the above solution styles? Are they development agencies or enterprises
  4. Real Talk: Current Gaps – What could be missing from Podio (and maybe Globiflow) to make it more “Product Platform” or “Mass Customize” oriented?
  5. Deep Dive: Podio’s API “readiness” for integrations and toolsets to enable more “Product Platform” or “Mass Customize” orientation.
  6. Audience Engagement: Solving Podio Gaps – Podio Developers and Power users – Submit your gap!
  7. Up Next: mPact Pro - How we built a full Podio-based product for a client from concept to revenue.


Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.

Support the show (http://www.brickbridgeconsulting.com/podcast)

Gil Roberts:

Hi, I'm Gil Roberts. Joining me today is Alex Shull Lead Developer at Brick Bridge Consulting and Jarett Duker who is our principal consultant here at Brick Bridge Consulting. This podcast is about podio if you do not know what podio is. You can check it out. Uh , Citrix is podio product at Podio, p o d I o.com. Today's topic is about podio as a product platform. I wanted to get in today and and understand if podio is the platform itself is positioned to deliver wide scale solutions. Alex will be giving a technical perspective today. Jared, we'll be doing a client in business perspective. And fellas, I just want to ask , uh , first and foremost, do you believe that podio is ready to deliver a wide scale solution?

Alex Shull:

Thanks, Gil. Um, yeah, this is Alex. I , I think that podio is a position to deliver wide scale solutions. Uh , and the , the key is that you have to know how to design solutions for podio. So it takes some attention to we're podio strengths are and where you need to make design choices that take advantage of those as strengths and avoid some of its limitations. Um , but we , we found an art to doing that and I think that podio can make improvements in that regard. But even today, it's already capable of delivering those solutions.

Gil Roberts:

These are great issues that you bring up. So , so I'm gonna say yes from you. Jarett. What about your opinion?

Jarett Duker:

Over the last couple of years we've noticed a trend throughout multiple different industry sectors, which is , uh, many, many of these sectors have the need for technological solutions but are not large enough to attract industry giants who are going to come in and design customized software to meet their needs. Podio represents a wonderful middle ground that allows a small organizations to quickly design and develop internal applications and get them into the market quickly.

Alex Shull:

And that's a good point. You're , because I, there are some of the strengths of podio is to actually deliver applications quickly. And the way that it is often used is by very small businesses or enterprises who are running perhaps five locations, 10 locations, and they can manage installations . Even if they're reinstalling a single APP multiple times , um, to help deal with um, branches or something like that, they can still manage it at the individual location level. However, if you take a solution and you start really addressing it as wide scale , that means you're expanding beyond those boundaries. And so when we're talking about why it's good , we're talking about you need the need for some automations, the need for some , um , aggregated reporting, perhaps the need for some , um , oversight , um , in a centralized location. And these are, these are solutions that podio is capable of, but they're not built directly in. And you need to do some customization to had to understand some of the automations.

Gil Roberts:

So let me unpack that further with you Alex. So when we start looking at podio solutions, things that are built on the podio platform and in the style of those, which I'll define a one off meeting , we work with a client and it's a onetime build, uh, and that's it. It's not really applicable to other clients. Something that's a mass customization, which we've done in a couple of industries where we've built something that can be replicated and then customize. So just like a core and then we go out and customize it from there or a full range of product, which we've done on of those, which is a complete product on one platform. So those are the three styles. So let's talk about the difference as a one off something that's kind of core and customize or mass customized or something podio used for a full product. Uh, do, do you feel there's a better way for each one of those is maybe all of above that , that podio for wide scale solution can handle all those? How do you guys feel about that?

Jared Duker:

Well, I think one off is definitely the standard that we've seen well represented throughout the market over the last five years. What we are exploring and where our interest really lies is in , uh , using podio as a template for creating mass customized solutions and eventually full products through use of their open API to connect , uh , and fill the gaps that may exist to create that , uh , that capability.

Alex Shull:

Yeah, that's the , that's exactly. Um, I think the strength of podio and that's why so many people when they first get a taste of it , they're getting a taste of it from the standpoint of a needing to solve their own problems. They understand the problems very well from a business perspective. They haven't found a good product that captures that business perspective. So they build their own solution. Maybe they're pulling data out of one system, you know, doing a little modifications and then pushing it into another system. Or maybe it's an application from the ground up. But either way, it's the ease of getting started in podio is what's attractive. Once you need to start taking that into an enterprise direction where you have to administrate many locations, you start facing the challenges. And there are some tools out there that help you, but a lot of them are not very mature and a lot of them , um , have their own limitations. And so there's , but the, if you can find the way to take a podio solution from that one off and you can find the way to manage it into , uh , a larger deployment, then podio is beautiful because it gives you that flexibility to respond, to iterate, and to really, really tune your solution to it's exact needs and still have something you can deliver at scale.

Gil Roberts:

So what you're saying here is , is the ability to scale is sitting there underneath the surface, but some of the tools just haven't reached a level of maturity that that's required to be able to extract that out , uh , and extrapolate it for, the benefits of agencies and enterprises to create those kind of wide scale solutions.

Alex Shull:

Yeah, and that's a, that's a good point. You just mentioned agencies , um, and you, we've talked about enterprises. These are different customer segments who can all take advantage of Podio, but they really represent a different set of needs and expectations when they approached podio in as a lot of podio users will know that, you know , there's a share file, um, aspect of the podio ecosystem and it has very, very complex password requirements that are attractive to the enterprise solution side. But podio doesn't have that natively in it. And so that just shows you that their offerings are out there. But the, there still a lot of segments who approach podio without needing that complexity. And so they don't want to build it into the front end. And so , um, so yes, there , there's, there's always , um, I lost my thread. Sorry. What was I saying?

Jared Duker:

Lets take a look at scalability and what does that actually mean and why does anyone care about it? Um, I see two applicable uses and why you would care about scalability. Let's imagine a large company that has say 500 employees who are all doing more or less the same job. Now imagine if they were all in one workspace together, all adding and manipulating items inside of one workspace. Yes, it could happen. But realistically what would want to see is multiple copies of the same workspace broken down by department or major managements , manager, sector, whatever it happens to be. The other usage would be a , uh , say franchise model where you have discrete locations, all performing similar functions, but ultimately want to keep their data separate. 10 to 15 users per workspace. Podio can do this, we can have 500 employees in a workspace, but we don't really want to, we can hand crank out 500 copies of one workspace, but frequently we don't really want to. So this is that first gap that we're talking about in terms of scalability. How do we take what has largely been used as a small business platform and turn it into an enterprise level solution, able to manage and route that level of data and that level of users.

Alex Shull:

Yeah. And then those same capabilities are valuable whether they're deployed within an enterprise where you really don't want to expose those services to the public for consumption. And it's just about getting your enterprise work done in a way that is manageable. You have audit controls, you, you know, where the software is running any who has access to it. Those are challenges that require some use advanced use of the podio API or some of the other tools like procfu that are out there to manage podio installations or our own platforms . Sassafras where you can use to manage podio installations. But then similarly, if you are a software developer who wants to use podio as a platform to quickly deliver value to clients and you can deliver it to 50 clients, how to manage a software distribution even from podio to 50 clients , um, is a challenge today. And so the tools that they were aiming to develop in the techniques we're aiming to teach make all that possible.

Gil Roberts:

Fantastic. So for the benefit of our audience here, who are the clients that might want to use different types of solutions styles? So Jared , you mentioned franchises. I think there was a great example. What are the kind of types of clients we can get into some detail? Maybe we keep it kind of a higher level archetypes of client. For those that are looking to scale across podio, who would that, who would that be

Jared Duker:

Over the last couple of years that we've been working now? Uh , using the podio platform. Uh , better question is. Who is it not? Every business is looking to grow and requires scalability inside of their technical solutions. Um, even small businesses frequently need to segment their data out and create what a minuscule scalability. Uh, just about every industry is encountering the same issues nowadays. It's not what to do with their data. It's how to manage the massive amounts of at that 2019 creates every single day. So such things as customer relationship management, product or inventory management, scheduling , um, case management, file management, record management. These are nightmares that exist in just about every single industry sector from lawn care all the way through high tech manufacturing. Uh , that's why I say who is not potentially the client.

Gil Roberts:

That's a fair put back. I mean really, there's so much data and process to be managed out in the world. Uh, it becomes hard for us not to fall into it , uh , as part of our daily jobs. At some point we have to deal with this.

Alex Shull:

Yeah. And I think that what is unique about the way that those are delivered today and the way that podio enables , um, us and others to deliver solutions today is that we can really approach any of these industries as a task of customizing what are largely similar , um, you know, things like orders and billing and, and customer management, but then being able to customize it or tailor it to this specific needs of German to lawn care. Well, lawn care businesses have to collect different information than I a , um, you know, a laundromat. Those are, those are different requirements. And oftentimes you have multiple systems that aren't well integrated for these industries. And if you can thread those pieces together and make the information flow all the way through the system, then you have a very smoothly operating business and you can do that affordably using solutions like podio.

Gil Roberts:

So somebody , uh , as I'm sitting here thinking this, somebody that say podio development shop like ours that has a lot of podio first development working , um, works that deal with clients and try to understand client requirements , uh, using something that's close to a core that can be then customize quickly so you can deploy out a core CRM system for a lawn care to give her an example and then customize around that. Now I know is there some challenges to doing that differ in present day?

Alex Shull:

In my experience, I'd like to do Jared's perspective on this, but in my experience, the biggest challenge is finding a person in the industry who really knows what they need and is able to put that not in a purely technical language, but just into those, into that language or requirements to where we as a consultant or anyone else who just has the core competencies of developing in podio and globiflow procfu and saassafras for us. These systems that let you quickly integrate together , um, completely bespoke software. Um, if they can figure out and say exactly what's needed, that's the, that's the magic sauce. They really make a great system out of podio.

Gil Roberts:

So our good old fashioned client needs to know what they want, right ? Yeah . I think that's fair.

Alex Shull:

If they can't accept the mediocrity of the systems that they've been burdened with. They have to have a vision for how to do things better. And they, and when we talked to them that we've, and we find people who know that then then podio is a great solution.

Gil Roberts:

So we need, we need somebody that's innovative moving into the industry. I guess there's just not a lot of out of the box podio solutions that you can pull down for your clients. Right. It's not a great market place that has prebuilt solutions by other development shops. Ours or others would be available to , to at least start with a template that is maybe tailored to the industry. So you're forced into what you're saying, where you have to go find somebody that that's innovative, that's motivated , uh , and that's willing to sit and work with a consultant, actually do the hard dirty work of designing software. I design software solutions .

Alex Shull:

I think that podio solutions are so easy to build that as soon as people get a taste of that and they're like, well, why would I want to use this here? I can, you know? And so a lot of the things that you pull down , um , out of the marketplace that are, that don't cost anything are very, very simple because no one, you know, to actually make them work well to really figure out exactly what's needed is effort and be , want to be compensated for that. And , and so I think that there's a little imbalanced in the current podio marketplace and that the solutions are just templates. You really not going to get as far as you need to go with what I've seen there.

Jared Duker:

And Alex really hit the nail on the head. The simplicity of the mechanics of creating a product on podio are so simple. But when we still frequently overlooked is the intellectual property that goes into that. The understanding of underlying why's that will allow you to string things together. And very frequently, even if you were to pull down and integrated product that had seen multiple apps and multiple workspaces, if you don't understand why things are moving between them, even small changes will shatter the entire solution. And you're back to square one anyway.

Alex Shull:

Yeah. And what are the biggest gaps? And if you, if you read the forums, if you go, if you joined the podio user groups, the globiflow user groups, one of the biggest issues that you'll see if you're a software developer trying to offer a solution through that marketplace, there's no way to patch a solution. Um, we sassafras has a way to patch solutions and , uh , that is something that, you know, we're, you know, we're interested in offering. You can reach out to us if you're interested in seeing what our offering is there. Um, but if without the ability to patch solutions, it's an impediment to being a software developer delivering , um, software that can improve over time on the podio platform.

Gil Roberts:

Yeah , patches are, is important. I think this brings us into a topic I was hoping for us to dive into today, which is just kind of current gaps inside the, the kind of the current podio ecosystem , podio, globiflow , Zapier procfu, um, our own solution. Sassafras is just smart phone them . It is a ton of these extensions that are being made out in the community. Integra mats . Another good one. Um, what is, why, why are we seeing some of this diversity in gap filling ? Let's, let's start with that rather than, than a swatch . Why are we seeing that? and why are we seeing that people instead of banding together around a particular, you know , like let's all try to help out globiflow or what's all try to help out talk through that. A lot of people are starting to splinter off.

Alex Shull:

I , I, you know, I, I have , um, a feeling that the podio team has lost a little bit of goodwill with, in all honesty, we love Podio, but we , there's been a little bit of goodwill lost in terms of delivering new features over the past year and it's been here stabilization and we all want stability. And we, I, we as developers or myself as a software developer, I understand the challenge of , of , of delivering a stable solution at that scale. And so it's not a small effort. Nonetheless. I think that there's been a little bit of goodwill lost . Um, however, the, the spirit of the people who use podio really seems to be , um, the people who are creative and they make solutions work and they figure out how to get systems together. Even though it's used within large organizations. There's something about the spirit of people who use it. They like to be able to wire it up to different solutions. And so even though globiflow comes on the platform , um, no one on the platform is dedicated to, you know, using another integration style is whatever works. People are very open to making it work. However, does, I don't know ,

Jared Duker:

I actually feel a little bit for the podio development team and I think there's a classic example of why they're doing what they're doing right now. So walk into a room of 10 people and say you're going to order a pizza and ask them what they'd like on it. You're going to spark a huge audience and there's a good chance you're going to end up. But just basic cheese or pepperoni. And that's what podio is really trying to do is to deliver that vanilla experience that people can build their own solutions off of. And because there's such a diverse demand , um, they are just letting the third party market , uh , step in, use the API to create these tools.

Alex Shull:

Yeah, that's a very good point in general because you know that that gives us the opportunity and others the opportunity to do that value added service and it doesn't integrate well with the market in terms of the way that we want to do work , um, with the podio market place . However , um, if there is a way to let third parties enhance the offerings , um, by leveraging what's already available and the Podio Api and so that, you know, that that's , they would have to have a bias if they were to take it in one direction, they would be potentially abandoning a certain segment of the users. But I want to , I want to point out one thing, and this may be a segue , the free accounts, they just put pretty significant limitations on them and I think that that is a move to get more paying users and try to address some revenue concerns they might have and hopefully that goes well for them and it only strengthens the hand of Podio

Gil Roberts:

Yeah, it's good . That's a good current event. Um, so they got limited to 500 items for free users. I , I see that as a development agency. Working with podio is an opportunity to be able to reach out to some of those , uh , higher volume free tier users , uh , to see if, you know, bring them on to a paid solution and how we can add value. So they feel good about paying for this , you know , and it's hard to convert somebody over from free, especially if they're getting everything they want. Right. I usually just leaves a bad a bad vibes. So , uh, just say I think an interesting point that you bring up for current events, but also I think there's a lot of opportunity for the podio development community to come to those users and go, look, this is a great platform. You should be paying for it. There's alot of that.

Alex Shull:

Yeah. That, that's our message you should be paying because when you pay, you get even a better product, you know ?

Gil Roberts:

Exactly. Over time. So , um, I think what I want to get into , uh , to wrap up our episode here , um, was just a little, a little deep dive into the API readiness for this kind of integration. More at a wider scale. You know, just in , especially in Alex, since your our technical guy here, what that Api looks like today, what it , what it feels like to get in there and go on it. A deep dive, but we'll, we'll keep it short.

Alex Shull:

I think that a podio is Api , um , has certain things that, you know, make it very strong for, you know , being in this position. And that's primarily just the, they have done a good job of separating the design of the applications and some of the other elements, for instance , um , messaging. By having that as a separate API, it makes it a much , um, architecturally better to see how this system integrates with people who don't want to use podio as their primary messaging. And so by keeping those things separate, they grant you the flexibility of leveraging podio without being , um, hard cooked, you know, hardwired into it. That those are just some aspects of , of the, of the API that I think are really positioned at well for , um, someone to invest in and feel comfortable. The other aspects that I think need a little improvement are , um, they're , they need to support cashing infrastructure. There's a lot of , um, benefits to building a good cashing architecture if you're, if you're delivering services on top of Podio the way that we are with Sassafras. Um , but I think that the podio API developers wanted to pay more attention to providing the , um , the cash directives and maintenance to where our , um , podio cash could more easily be responsive, and be more efficient than those are the things that I, I would, I would like to see happen.

Jared Duker:

Alex. Um, you've been working on the Podio Api for about 18 months now. Um, and coming back to our focus on scalability of the podio platform , uh, we, we've already established a Citrix is more interested in establishing the sandbox that really building anything in it. So third party developers are using this API to deliver these services. In your experience, how ready is the Podio Api for enterprise level and utilization with third party services

Gil Roberts:

At scale?

Jared Duker:

At scale? Exactly.

Alex Shull:

Well, the , the , the only issue that we've seen repeatedly is the delayed web hooks . And delay calculations. Now those aren't strictly the API. The API is that interface where you get to , um, call in and it's , it's it times out. Once in awhile you have to have a software infrastructure that deals with things like timeouts. It pretty responsive and it's , um, I calling the API as has never been our issue. The issue that podio users have experienced that causes pain are delayed web hooks in delayed calculations. They worked out their calendar issues and it's the, that's been a very good direction. Um, that I think that if they can improve to where the web hooks aren't delayed, I don't think any, any enterprise has a concern. Now from, from our perspective developing Sassafras, we tried to build our systems to where they're resilient to , um, you know, meeting the requirements even if led hooks are delayed and we can explain how that's done and in future podcasts and, and how we achieve that kind of reliability. Um, but that's separate from podio itself. If there , there are ways in which I would say that for a mission critical system , um, you can't put it on, on Podio, podio today. Um, if you look at history or performance, you, you can't, you know , um, run surgery on it.

Gil Roberts:

That's fair. So, what you're saying is some of these things that are maybe not Api centric but API related such as the web hooks that you guys are utilizing that

Alex Shull:

It's part of the integration mechanics. If you're trying to take advantage of the podio platform and with any distributed system, you're relying upon network connections that are unreliable. It's just one of the aspects of the Internet. And so podio as a system , um, if you take it at the approach that we do, where we use that integration model of delivering value , um, that I think , um, it's just, it's just part of the game that you're in. You can , um, achieve a higher degree of reliability by playing pain a lot more money. And most, most , um, the, the reliability that we're talking about again , um , is not going to affect your, your day to day business operations and things like that. And it is perfectly well suited for, you know, keeping the office of opening and keeping the business running. It's not something that you want to run a air traffic controller at west .

Gil Roberts:

Yeah. Something that's got to get through to that.

Jared Duker:

That's an important distinction when we talk about a suitability of products from various sectors. Yeah . And that's definitely going to go up on the board.

Alex Shull:

Yeah. And yeah, and that's it . It's always don't understand podio is there is a core system that can very , very flexibly and in a very , um, internet, you know, first way manage the , the , the core information and the core processes of your business. And if you have some high performance, you know, ordering front end for a web store, you know, build that on podio. Podio is a consumer of that information. And likewise, if you have , um , some other, you know, customer , um, you know , um, value delivery that needs to be available 24/7 with millisecond response time that podio is not your platform for that. So you have to understand what you're building. Sure .

Gil Roberts:

So , and , and basically what I'm hearing and what I would have gathered from today's episode, yes, it's , it's positioned to deliver our original question is in any position to do so. And that is yes it is doing so in certain instances. Um, it has some, some gaps that need to be addressed to make it more of a solidified product , uh , that we can use to launch more products on we being the developer community. Um , and , and in the end, podio is really the thread that may be tying a bunch of different systems together so that if you do need that millisecond response time, you can develop something smaller that kind of handles that, that then goes to the podio platform, maybe something that parses those, you know, you get orders every other, you know, three or four seconds, it can kind of parse through those and then spit out those ordered cue into podio for fulfillment, which isn't going to be boxes a second write about human beings .

Jared Duker:

I think Alex said something very critical and I'm looking forward to discussing it in future episodes, which is podio, a consumer of data or an originator of it? And it's two very different sides of a coin, but both have a place in any sort of a usage model.

Alex Shull:

And that , well, that's , that's one of the questions that we always ask when we're working with our clients because we tried to break our, our consultations into a work practice and a data practice. And so you start on the work practice, you say what ? What is your actual work? What are your actual core processes? Without getting into the details of business logic and those aspects that you have to address once you start building a podio system. But when you, when you address that question, you have to know at the outset what purpose is podio serve . And so oftentimes in the enterprise context, you talked about a golden record and if podio is your , your system of record and it holds the , the truest copy of your data, those are architectural decisions you have to make before you start building your system.

Gil Roberts:

Did design in the solution is always important as what I'm hearing here. Well , I want to have first appreciate everybody listening to our very first podcast. We hope that our conversations grow from this, that we can continue to provide value to the developer community. Uh , what we're going to do on our next show is actually go through a in a few pieces , uh , a large client that brokerage consulting started with , uh , how we service that client, some of the technical aspects. So we'll be looking at both the design as well as the technical things that we need needed to do against the API. Uh, other, other things inside of that episode. We'll have that as a series of three episodes and we're looking to get actually our client on as an interview to get their perspective of what it looks like to have a product , uh , bulid completely podio first on the podium platform. Uh, in between them we also are looking for you guys to make some submissions of gaps in Podio , uh, that, that you wish would be solved. We have tons of them on the user's, user forms use those. If they've been sitting around and languishing for awhile , but we encourage you to submit that. It's going to be at podcast@brick bridgeconsulting.com. That's B R, I, C, K Bridge, B R, I, D, G, E Consulting.com and again, I appreciate everybody that's listening in today. Uh , when the first podcast, this was the podio solutions podcast episode one, season one. Thanks. And we will be returning next week

Alex Shull:

Thanks!

Jared Duker:

Thank you all!